Connect AI assistants to your Wayfront agency workspace. Manage clients, orders, services, forms, and support tickets; review invoices and subscriptions; and search Wayfront documentation. Uses OAuth 2.1 and respects the connected user's workspace permissions.
Scored across 50 tools
Most tools map cleanly to distinct resources via read/write pairs, and descriptions clarify boundaries between close concepts like client vs company and order-message vs ticket-message. A few pairs (team-tool vs team-management-tool, service-read vs order-task-read) could still cause an agent to hesitate, but there is no severe overlap.
The dominant <resource>-read / <resource>-write pattern is predictable and covers the majority of tools. However, several holdouts (invoice-tool, log-tool, subscription-tool, team-tool, team-management-tool, get-wayfront-doc, search-wayfront-docs, workspace-info) break the pattern without a consistent alternative.
At 50 tools this is a very heavy surface for an agent to navigate, far beyond the well-scoped 3-15 range. Even though the underlying platform is broad, the sheer number of endpoints makes discovery and selection costly.
Read/write coverage is solid across most resources, but several lifecycles have notable gaps: orders can be updated but not created, tags and coupons can be created/updated but not deleted, and team management lacks removal operations. These missing operations will force agents into workarounds for common management flows.
List a pipeline's automation rules and the catalog of supported triggers, conditions, actions and references. Requires pipeline_id.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| pipeline_id | Yes | The pipeline the automation belongs to. Required for every action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'List' wording aligns with the readOnlyHint and destructiveHint annotations, and it does not contradict them. It adds functional context about the catalog, though it does not discuss permissions or rate limits; annotations already cover the primary side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the tool's purpose and key requirement without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, mentioning the automation rules and the supported catalog gives a reasonable sense of what will be returned. It could be more explicit about output shape or filtering, but it is sufficient for a simple read/list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides clear descriptions for both parameters, including the enum action and the meaning of pipeline_id. The description reinforces that pipeline_id is required but adds little beyond the schema's existing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists a pipeline's automation rules and the supported catalog of triggers, conditions, actions, and references. The read-only intent is unambiguous and easily distinguished from the sibling automation-write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that pipeline_id is required for every action, which gives necessary invocation guidance. It does not explicitly mention when not to use it or contrast with automation-write, but the read-only wording and sibling name make the appropriate use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, toggle or delete pipeline automation rules. Every action requires pipeline_id. Read automation-read first for supported triggers, conditions and actions. Active rules can trigger downstream writes, webhooks or Slack messages. Status-sync-managed rules cannot be edited.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Rule name. Required for "create"/"update". | |
| action | Yes | Action to perform. | |
| actions | No | Action list ({type, params}). Valid types + their params come from the "list" catalog. At least one action is required for "create"/"update". | |
| conditions | No | Condition list ({field, operator, value}); all must pass (AND). Use fields/operators from the "list" catalog for the chosen trigger. Pass an empty array for no conditions. | |
| pipeline_id | Yes | The pipeline the automation belongs to. Required for every action. | |
| automation_id | No | Automation ID. Required for "update", "toggle", and "delete". Use "list" to discover IDs. | |
| trigger_event | No | The trigger event slug (e.g. "order.status.changed"). Must be valid for the pipeline type — see the "list" catalog. Required for "create"/"update". | |
| description_cache | No | Optional human-readable summary of the rule (use real names, not IDs). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important side effects (downstream writes, webhooks, Slack messages) and a restriction (status-sync-managed rules cannot be edited), going beyond the annotations' destructiveHint. This gives the agent a clear picture of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a few short sentences. It states the core function, key requirements, and important caveats without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema, the description covers the essential context: it lists supported actions, mentions the need to read the catalog, and highlights side effects and edit restrictions. It does not describe return values, but that is a minor gap for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description does not add much beyond it. It reiterates that pipeline_id is required and references the 'list' catalog, but these details already exist in the parameter descriptions. The baseline for high coverage is 3, and no significant extra meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function with a specific verb ('Create, update, toggle or delete') and a clear resource ('pipeline automation rules'). This distinguishes it from the sibling automation-read tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises reading automation-read first for supported triggers/conditions/actions, giving a clear usage order. While it doesn't explicitly say 'use this when you need to modify automations', the intent is obvious and the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List client custom-field definitions, IDs, types and options.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the specific output scope (definitions, IDs, types, options), which provides useful behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is entirely relevant and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and no output schema, the description fully conveys what the tool does and what it returns. No critical information is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'action' has 100% schema coverage with an enum description ('Action to perform.'). The description does not add any additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and a specific resource ('client custom-field definitions'), and enumerates the exact data returned (IDs, types, options). This distinguishes it from the sibling 'client-custom-field-write' and other read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and description make the use case obvious—reading custom-field definitions. While no explicit exclusions or alternative tools are named, the distinction from the write counterpart is implicit and sufficient for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or clear a client custom-field value. Requires client_id, field_id and value; null clears the value. Discover definitions with client-custom-field-read. File-type fields cannot be set through MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Value to set. For checkboxes use "1" for checked or "0" to uncheck. For dropdowns use one of the field's items. Pass null or omit to clear any field. | |
| action | Yes | Action to perform. | |
| field_id | No | Custom field ID. Required for "set" action. Use "list" to discover available field IDs. | |
| client_id | No | Client ID. Required for "set" action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Openly describes modifying/clearing data and notes that file-type fields cannot be set via MCP, which is consistent with destructiveHint=true. It does not mention irreversibility, but the destructive nature is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler; each sentence adds necessary operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers required inputs, clear/update semantics, read-tool discovery, and a key limitation. No return-value details are provided, but no output schema exists and this is a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptive schema text, and value encoding for checkboxes, dropdowns, and null-clearing is explained in detail. There is a slight inconsistency between the required array and the prose requirements, but the field-level descriptions compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Set or clear') on a specific resource ('client custom-field value') and points to the read tool for discovering definitions, so its purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage details: required identifiers, null-clearing behavior, and the file-type-field limitation. It does not explicitly discuss alternative write tools for unsupported fields, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show visible client accounts with filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, email, role, role_id, accounts.id, status_id, managers, manager_id, pipelineItems, optin, created_at, updated_at. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, email, role, role_id, accounts.id, status_id, managers, manager_id, pipelineItems, optin, created_at, updated_at. Status filter key is "status_id" (numeric IDs, not string names): 1=Contact, 2=Lead, 3=Client, 4=Client Team. Marketing opt-in filter key is "optin": 1=opted in, 0=opted out (shows the "Outreach opt-out" badge), use the $null operator for never answered. | |
| client_id | No | Client ID. Required for "show" action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'visible' qualifier, which implies some accounts may be hidden, but does not explain the mechanism or consequences. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and resource, and includes the key capabilities (filtering, sorting, pagination). No waste, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a fully described schema (6 params, nested filters, enums), the description is adequate. It does not explain return formats, but no output schema exists and the action semantics (list vs show) are implicit in parameter names and schema descriptions. The 'visible' nuance is a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters, including enums, defaults, and filter field examples. The description's mention of filtering, sorting, and pagination adds no meaning beyond what the schema already provides, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (list/show) and resource (client accounts) clearly, and mentions filtering, sorting, and pagination. It is specific enough to differentiate from client-write (which mutates) and client-custom-field-read (different resource), though it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention client-write, client-custom-field-read, or other read tools, nor any conditions that would favor one over the other. The 'visible client accounts' phrase hints at a scope but is not actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a client account. "create" requires email; welcome_email defaults to true and can send an external welcome email. "update" is a partial update of an existing client's profile: omitted fields are left untouched, and an explicit null clears a field (email cannot be cleared).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Client note. Max 65535 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| No | Client email address. Required for "create". Optional for "update" — cannot be cleared to null. | ||
| optin | No | Marketing opt-in flag. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| phone | No | Client phone number. Max 64 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| action | Yes | Action to perform. | |
| name_f | No | Client first name. Max 64 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| name_l | No | Client last name. Max 64 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| tax_id | No | Client tax ID. Max 255 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| address | No | Address: line_1, city, state, postcode, country (2-letter code). For "create" and "update". On "update", provided fields are merged into the existing address (or a new address is created if none exists); omit the whole object to leave the address untouched — null is also treated as untouched, not cleared. | |
| balance | No | Optional starting client balance. "create" only. | |
| company | No | Client company name. Max 255 characters. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| client_id | No | Client id. Required for "update". | |
| status_id | No | Client status ID. For "create" and "update"; omit to use the model default on "create" or leave untouched on "update". Cannot be null or empty. | |
| stripe_id | No | Stripe customer ID. Must be unique. For "create" and "update"; omit to leave untouched on "update", null to clear. | |
| created_at | No | Optional creation date/time. "create" only. | |
| welcome_email | No | Whether to send the welcome email. Defaults to true. "create" only. | |
| referrer_user_id | No | Referring client ID. Must be a different client. For "create" and "update"; omit to leave untouched on "update", null to clear. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: welcome_email defaults to true and can send an external email, update is partial with omitted fields untouched, null clears fields, and email cannot be cleared. It also notes address merge behavior. Annotations already indicate destructiveHint=true, so the description adds meaningful context beyond that. It doesn't mention side effects like email sending beyond welcome_email, but the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. It packs significant behavioral detail into a few sentences without redundancy. It could be slightly more structured, but it earns its place with high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 params, nested address object, two actions with different requirements), the description covers the critical semantics: create vs update, null clearing, email constraints, and address merging. It doesn't explain return values, but there is no output schema and the description focuses on invocation semantics. It is complete enough for an agent to call the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the create/update distinction and the null-clearing semantics, which are not fully obvious from the schema alone. It also clarifies the address merge behavior and email constraints. This goes beyond the baseline 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a client account, and distinguishes the two actions with their key semantics. It names the resource (client account) and the specific operations, making it easy to differentiate from sibling read tools like client-read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use 'create' vs 'update' and highlights important constraints like email being required for create and not clearable on update. It doesn't explicitly name alternative tools, but the action enum and per-field notes provide clear usage context. It could be improved by explicitly stating when to prefer client-write over other write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show client companies (client teams). A company groups client accounts that collaborate: members with collaborate_on_new_orders/collaborate_on_new_tickets are added as collaborators on the company owner's new orders/tickets, and members with access_invoices can see invoices belonging to the owner. The owner decides whose invoices members with invoice access see. "list" supports the standard filters/sort/limit/page plus client_id, which finds the companies a given client belongs to, whether as a member or as the owner. "show" returns the owner, whether the owner is also a member (owner_is_member), and every member with their three flags.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, name, owner_id, created_at, updated_at. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, name, owner_id, created_at, updated_at. | |
| client_id | No | Filter "list" to companies where this client is a member or the owner. | |
| company_id | No | Company id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral context beyond the readOnlyHint and destructiveHint annotations: collaboration flags, invoice visibility rules, owner_is_member behavior, and what show returns. This gives an agent a realistic model of the tool's domain effects without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but well-structured, front-loading the purpose before explaining domain rules and action-specific details. It is longer than average, but the added context about collaboration and invoice visibility earns its place for a domain with nested semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value information. It explicitly states what show returns and implies list returns standard company records. Given the tool's moderate complexity and 7 parameters, the description is largely complete, though list output details are not fully spelled out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that client_id finds companies where the client is a member or owner, that company_id is required for show, and by clarifying which parameters apply to which action. This is helpful semantic context beyond the raw field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "List or show client companies (client teams)." It distinguishes the two actions, list and show, and explains the core concept of a company grouping client accounts. This clearly separates it from the sibling company-write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete guidance on when to use each action: list for filtered queries including finding companies by client_id, show for retrieving owner and member details. It does not explicitly name company-write as the mutation alternative, but the readOnly annotation and sibling naming make the boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
List or show discount coupons with filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, code, description, type, discounts, date_expires, new_customers, single_use, single_quantity, duration, is_cart_total, used_count, min_cart_amount, created_at, updated_at, deleted_at, coupons.id, coupons.code, coupons.description, coupons.type, coupons.discounts, coupons.date_expires, coupons.new_customers, coupons.single_use, coupons.single_quantity, coupons.duration, coupons.is_cart_total, coupons.used_count, coupons.min_cart_amount, coupons.created_at, coupons.updated_at, coupons.deleted_at, affiliate. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, code, description, type, discounts, date_expires, new_customers, single_use, single_quantity, duration, is_cart_total, used_count, min_cart_amount, created_at, updated_at, deleted_at, coupons.id, coupons.code, coupons.description, coupons.type, coupons.discounts, coupons.date_expires, coupons.new_customers, coupons.single_use, coupons.single_quantity, coupons.duration, coupons.is_cart_total, coupons.used_count, coupons.min_cart_amount, coupons.created_at, coupons.updated_at, coupons.deleted_at, affiliate. | |
| coupon_id | No | Coupon id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and non-destructive behavior, and the description adds concrete behavioral details about list/show actions, filtering, sorting, and pagination. There is no contradiction between the description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is a single, front-loaded sentence that states the resource, actions, and key capabilities. The longer field lists live in the schema and do not bloat the prose description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately conveys that the tool returns coupon data and supports pagination. It does not spell out the exact response shape or error behavior, but the core context for invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters, so the baseline is 3. The description adds available field lists and a filter example, but much of this repeats the schema and the 'Purity filter' phrasing is unclear, providing only marginal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reading discount coupons via 'list' or 'show' actions and mentions filtering, sorting, and pagination. It does not explicitly distinguish itself from the sibling coupon-write tool, though the name and actions make the read purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus coupon-write or other read-oriented sibling tools. It lacks explicit context such as 'use for read-only coupon access' or 'use coupon-write for modifications.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update discount coupons. Requires coupon permission. Creation requires a unique code, type and discounts; percentage discounts cannot exceed 100. Updates replace supplied discount collections and can affect what clients pay.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Coupon code (max 32, unique). Required for "create", optional for "update". | |
| type | No | Discount type: "percentage" (amount is 0–100 percent) or "fixed" (amount is a monetary value). Required for "create". | |
| action | Yes | Action to perform. | |
| duration | No | Whether the discount applies for the full subscription duration. Optional. | |
| coupon_id | No | Coupon id. Required when updating an existing record. | |
| discounts | No | Discount rules. Required for "create". Each entry has an "amount" and optional "services". | |
| single_use | No | Allow each customer to use the coupon only once. Optional. | |
| description | No | Internal description of the coupon. Optional. | |
| date_expires | No | Expiry date-time (e.g. "2026-12-31 23:59:59"). Optional; pass null on "update" to clear. | |
| is_cart_total | No | Fixed coupons only: take the amount off the eligible cart subtotal once, spread across the eligible items, instead of off every eligible item and quantity. Ignored (forced false) for percentage coupons. Optional. | |
| new_customers | No | Restrict the coupon to customers with no prior paid invoices. Optional. | |
| min_cart_amount | No | Minimum cart total required to use the coupon. Optional; pass null on "update" to clear. | |
| single_quantity | No | Apply the discount to a single quantity only. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write and destructive behavior. The description adds useful context by explicitly warning that updates replace supplied discounts and can affect what clients pay, which goes beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and packs essential operational details into two sentences without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers the necessary context: permissions, required inputs, update behavior, and financial impact. It is sufficiently complete for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds meaningful constraints not obvious from types alone, such as 'required for create', 'pass null on update to clear', percentage limits, and fixed-coupon behavior. This strongly supports correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or updates discount coupons, distinguishing it from the read-only sibling coupon-read. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions required coupon permission, creation requirements (unique code, type, discounts), and warns that updates replace discount collections. It does not explicitly say 'use coupon-read for retrieval', but the create/update framing makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show form folders with filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, parent_id, name, type, description, sort_order, created_at, updated_at, form_folders.id, form_folders.parent_id, form_folders.name, form_folders.type, form_folders.description, form_folders.sort_order, form_folders.created_at, form_folders.updated_at, forms, parent, children. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, parent_id, name, type, description, sort_order, created_at, updated_at, form_folders.id, form_folders.parent_id, form_folders.name, form_folders.type, form_folders.description, form_folders.sort_order, form_folders.created_at, form_folders.updated_at, forms, parent, children. | |
| form_folder_id | No | Form folder ID. Required for "show". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true and destructiveHint false, and the description 'List or show' is consistent with no side effects. There is no contradiction, though the description adds no additional behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, and parameter descriptions are concise without redundant fluff. No unnecessary text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description adequately covers actions and parameter usage, including defaults and action-specific requirements. There is no output schema, so return format is not needed, and the read-only annotation and sibling naming add sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and descriptions clarify action-specific applicability, such as 'Required for show' and 'for list'. The filter description includes an example and the sort description explains the :asc/:desc syntax, adding useful meaning beyond basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List or show' and the resource 'form folders', along with filtering, sorting, and pagination. The title 'Read Tool' distinguishes it from the sibling form-folder-write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for read operations but does not explicitly state when to use this tool versus alternatives such as form-folder-write. The read-only annotation and sibling naming provide context, but no explicit 'use this when' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a form folder. Requires name and type. A parent folder must have the same type; nesting is limited to five levels. To file a form, use form-write with folder_id.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Folder name (max 64). Required for "create". | |
| type | No | The form type this folder organizes (order, contact, intake, onboarding). Required for "create". | |
| action | Yes | Action to perform. | |
| parent_id | No | Optional parent folder ID to nest this folder under. Must be the same type and no deeper than 5 levels. For "create". | |
| description | No | Optional folder description (max 1000). For "create". | |
| form_folder_id | No | Form folder ID. Required for "show". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral constraints: parent folder must match type and nesting max 5 levels. No contradiction with annotations; readOnlyHint false and destructiveHint false align with a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler. All sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation constraints and points to form-write for filing, enough for a simple create tool without output schema. The presence of form_folder_id for 'show' in schema while action only lists create creates minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 6 params with descriptions; description reinforces that name/type are required for create and explains parent_id constraints. form_folder_id is described but action enum only supports create, a minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a form folder and distinguishes it from form-write by saying filing forms goes there. Names the resource and action precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains required inputs (name, type), parent same type, and 5-level nesting limit, plus directs to form-write for filing. Could more explicitly state when to use this vs read tool, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show forms and their fields and linked services. Lists support filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, folder_id, access_key, type, name, info, public, custom_code, redirect_url, coupon, created_at, updated_at, forms.id, forms.folder_id, forms.access_key, forms.type, forms.name, forms.info, forms.public, forms.custom_code, forms.redirect_url, forms.coupon, forms.created_at, forms.updated_at, form_fields, services, assignedServices, folder, onboarding_forms, rules, logs. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, folder_id, access_key, type, name, info, public, custom_code, redirect_url, coupon, created_at, updated_at, forms.id, forms.folder_id, forms.access_key, forms.type, forms.name, forms.info, forms.public, forms.custom_code, forms.redirect_url, forms.coupon, forms.created_at, forms.updated_at, form_fields, services, assignedServices, folder, onboarding_forms, rules, logs. | |
| form_id | No | Form id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the data returned ('forms and their fields and linked services') and mentions filtering/sorting/pagination. Since the annotations already declare readOnlyHint, openWorldHint, and destructiveHint, the description provides a bit more behavior insight without needing to repeat safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose ('List or show forms') and follows with key details. No fluff or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a reasonable idea of what to expect (forms, fields, linked services) and mentions list capabilities. Since there is no output schema, the description provides enough context for an agent to understand the tool's scope, though it lacks details on the response structure or difference between list/show responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters (100% coverage per context), including detailed examples for sort and filters. The tool description itself does not add extra meaning beyond the schema, but the schema is already clear, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List or show forms and their fields and linked services.' It uses specific verbs (list/show) and identifies the resource (forms), making it easy to distinguish from write tools like form-write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that 'Lists support filtering, sorting and pagination,' giving some usage guidance for the list action. However, it does not explicitly state when to use this tool versus alternatives (e.g., form-write for modifications) or provide conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update forms. Creation requires type, name and the full initial fields list. Updating fields replaces the full list and deletes omitted fields; preserve existing field IDs. Omit fields to change form settings only. Order/contact forms require email, and order forms require a service-bearing field. Field edits are blocked for forms with white-labeled services.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Form description/instructions shown to users. Optional. | |
| name | No | Form name. Required for "create", optional for "update". | |
| type | No | Form type. Required for "create". | |
| action | Yes | Action to perform. | |
| coupon | No | Enable coupon field on order forms. Only applicable to order forms. | |
| fields | No | Form fields. Required for "create" (min 1). For "update": include id to edit, omit id to create new, fields not listed are deleted. | |
| form_id | No | Form id. Required when updating an existing record. | |
| folder_id | No | Folder ID to organize the form. Set to null to remove the form from all folders; omit to leave it unchanged. The folder must match the form type. | |
| access_key | No | URL-safe access key for the form. Optional, auto-generated if not provided. | |
| redirect_url | No | Redirect URL after contact form submission. Only applicable to contact forms. | |
| has_sidebar_link | No | Show link in client portal sidebar. Only for order and onboarding forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly discloses destructive behavior: 'Updating fields replaces the full list and deletes omitted fields; preserve existing field IDs.' Also notes 'Field edits are blocked for forms with white-labeled services.' These details go beyond the annotations (destructiveHint) by explaining exactly what happens, making behavior fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, with the primary purpose stated first ('Create or update forms.'). Each subsequent sentence adds a distinct, necessary detail without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and nested field objects, the description covers key behavioral rules (replacement/deletion semantics, form-type requirements, white-label blocking) while relying on the fully covered schema for parameter details. It provides sufficient context for correct invocation without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all 11 parameters, so baseline is 3. The description adds cross-parameter semantics such as 'Creation requires type, name and the full initial fields list' (conditional requirements) and 'Order/contact forms require email' (domain rules not obvious from individual parameter descriptions), providing additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create or update forms,' which clearly names the verb and resource. It distinguishes this write tool from siblings like form-read and form-folder-write by focusing on form creation/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance such as 'Creation requires type, name and the full initial fields list' and 'Omit fields to change form settings only.' It also notes domain rules like order forms requiring a service-bearing field. However, it does not explicitly state when not to use this tool versus alternatives, though the context makes it inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a current Wayfront help-center document using a document_id returned by search-wayfront-docs. Returns the canonical source URL and bounded document content.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Document ID returned by search-wayfront-docs. Do not guess IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate read-only and non-destructive behavior, the description adds transparency by specifying what is returned (canonical source URL and bounded document content), which is not covered 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey the action, the input, and the output. No unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the key contextual details: the source of the ID, the action, and the return type. It could be slightly more explicit about what 'bounded document content' entails (e.g., size limits or format), but it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter document_id is well described as an ID returned by search-wayfront-docs, with a warning not to guess IDs. This fully covers the parameter's meaning and source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve) and the resource (Wayfront help-center document), and distinguishes it from the related search tool by specifying that it uses a document_id from search-wayfront-docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using a document_id returned by search-wayfront-docs' implies the correct workflow (search first, then retrieve), providing context on when to use this tool. However, it does not explicitly name alternatives or state when not to use it, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query invoices. Actions: "list" — query invoices with filtering, sorting, pagination. "show" — get a single invoice by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, deal, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, deal, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. Status filter key is "status" (numeric IDs, not string names): 0=abandoned, 1=paid, 6=partially_paid, 5=payment_pending, 8=refund, 4=refunded, 3=unpaid, 7=void. | |
| invoice_id | No | Invoice id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate the read-only nature. The description adds the behavioral context of supporting filtering, sorting, and pagination, which is helpful, but it does not disclose additional details like response format, error behavior, or any edge cases. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, immediately front-loads the primary purpose ('Query invoices'), and efficiently encapsulates both actions without redundancy. Every word earns its place, and the structure is clean and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description is sufficiently complete for an agent to understand how to invoke the tool: it explains both actions and the general capabilities. The schema provides all parameter details, and annotations cover safety. The only minor omission is that it does not explicitly state that 'invoice_id' is required for 'show', but that is present in the schema, so the description does not need to repeat it. Overall, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning every parameter is documented in the schema with descriptions and examples. The tool description mentions the actions and general capabilities (filtering, sorting, pagination) but adds no parameter-specific information beyond what the schema already provides. Given high coverage, the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query') and resource ('invoices'), and explicitly distinguishes the two actions 'list' (with filtering, sorting, pagination) and 'show' (single invoice by ID). This makes the tool's purpose unambiguous and separates it from any potential confusion with sibling tools, even though there is no dedicated invoice-read sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use each action ('list' for queries with filtering/sorting/pagination, 'show' for a single invoice by ID), which serves as internal usage guidance. It doesn't explicitly address alternatives across tools, but since invoice-tool is the only invoice-related tool among the siblings, the intended context is clear and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List logs. Action: "list" — query logs with Purity filtering, sorting, pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, loggable_type, loggable_id, user_id, owner_id, event, data, created_at, updated_at, logs.id, logs.loggable_type, logs.loggable_id, logs.user_id, logs.owner_id, logs.event, logs.data, logs.created_at, logs.updated_at, user, loggable. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, loggable_type, loggable_id, user_id, owner_id, event, data, created_at, updated_at, logs.id, logs.loggable_type, logs.loggable_id, logs.user_id, logs.owner_id, logs.event, logs.data, logs.created_at, logs.updated_at, user, loggable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with a read-only listing operation. The description adds no additional behavioral details beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficiently communicates the tool's purpose and key capabilities without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for invoking a list operation, including filter and sort field lists. It does not describe the return shape, but for a straightforward list operation this is not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions, and the filter parameter includes an example and a list of available fields. The sort parameter also enumerates valid fields. This goes beyond basic schema coverage and helps clarify how to construct queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing logs. It identifies the resource ('logs') and the action ('list'), and distinguishes it from sibling tools by the specific log-domain focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys usage context by explaining that the tool supports filtering, sorting, and pagination for log queries. It does not explicitly compare to alternatives, but the purpose is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List messages for a visible order, including whether each message is staff-only. Requires order_number; supports filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| sort | No | Sort fields. Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media. | |
| limit | No | Results per page. Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object. Keys are field names, values are operator objects. Example: {"status":{"$eq":"active"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media. | |
| order_number | Yes | Order number. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds useful behavioral context beyond the schema: the 'visible order' precondition, the staff-only field in results, and support for filtering, sorting, and pagination. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that states the main action first, then the key prerequisite and capabilities. No filler or redundancy; every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a workable overview for a basic list call, but it does not define what makes an order 'visible' nor describe the output shape beyond the staff-only flag. With no output schema, some return-structure information would help; still, the rich parameter schema compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters in detail. The description adds a high-level statement about requiring order_number and supporting pagination/sorting/filtering, but it does not explain parameter meanings beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'List messages for a visible order' — and adds a distinguishing detail: 'including whether each message is staff-only.' This clearly separates it from write siblings like order-message-write and from ticket-message-read by scoping to orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (reading messages for a specific order) and states a prerequisite ('Requires order_number'), but it does not explicitly contrast with alternatives such as ticket-message-read or order-message-write. Usage context is present, but when-not-to-use guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a message to an order. Requires order_number and message. staff_only defaults to true; false can notify the client. The normal notification, webhook and broadcast pipeline runs; sent messages cannot be recalled.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| message | No | Message body (plain text or HTML). Required for "create" action. | |
| staff_only | No | If true, message is only visible to staff. Defaults to true for "create". | |
| order_number | Yes | Order number. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by warning that sent messages cannot be recalled and that the normal notification, webhook, and broadcast pipeline will run. This makes side effects and irreversibility explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: three sentences cover purpose, requirements, defaults, side effects, and irreversibility without unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with no output schema and no nested objects, the description includes the necessary purpose, inputs, defaults, and side effects. It does not address error conditions or return behavior, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all four parameters with descriptions, and the tool description adds meaningful context around order_number, message, and staff_only behavior. It does not add validation details, but the provided semantics are sufficient for basic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Post a message to an order.' It identifies the resource, the operation, and the required inputs, leaving no ambiguity about the tool's primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides practical usage details such as requiring order_number and message, the staff_only default, and the client-notification behavior when set to false. It does not explicitly contrast with read-only alternatives, but the write-oriented purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show visible orders with filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, number, user_id, invoice_id, subscription_id, service_id, service, date_started, date_due, next_task_due_at, nearest_due_at, date_completed, status, price, quantity, deadline, note, sort_order, last_message_at, created_at, updated_at, provider_order_id, provider_status, provider_error, deleted_at, orders.id, orders.number, orders.user_id, orders.invoice_id, orders.subscription_id, orders.service_id, orders.service, orders.date_started, orders.date_due, orders.next_task_due_at, orders.nearest_due_at, orders.date_completed, orders.status, orders.price, orders.quantity, orders.deadline, orders.note, orders.sort_order, orders.last_message_at, orders.created_at, orders.updated_at, orders.provider_order_id, orders.provider_status, orders.provider_error, orders.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, user, invoice, options, subscription, order_service, order_status, forms, addons, tickets, tasks, workflowSteps, media, linkedOrdersAsSource, linkedOrdersAsTarget, trackedTimes, pipelineItems, tags, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, number, user_id, invoice_id, subscription_id, service_id, service, date_started, date_due, next_task_due_at, nearest_due_at, date_completed, status, price, quantity, deadline, note, sort_order, last_message_at, created_at, updated_at, provider_order_id, provider_status, provider_error, deleted_at, orders.id, orders.number, orders.user_id, orders.invoice_id, orders.subscription_id, orders.service_id, orders.service, orders.date_started, orders.date_due, orders.next_task_due_at, orders.nearest_due_at, orders.date_completed, orders.status, orders.price, orders.quantity, orders.deadline, orders.note, orders.sort_order, orders.last_message_at, orders.created_at, orders.updated_at, orders.provider_order_id, orders.provider_status, orders.provider_error, orders.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, user, invoice, options, subscription, order_service, order_status, forms, addons, tickets, tasks, workflowSteps, media, linkedOrdersAsSource, linkedOrdersAsTarget, trackedTimes, pipelineItems, tags, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is "status" (numeric IDs, not string names): 1=Pending, 2=Submitted, 3=Complete, 4=Canceled, 5=Working. | |
| order_number | No | Order number. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'visible orders' hints at permission-based visibility, but this is vague and does not clearly disclose behavioral implications. The annotations already cover read-only and non-destructive behavior, so the description adds little beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, stating the core function in a single sentence without unnecessary detail or repetition. It is immediately scannable and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema provides extensive technical details, the description alone is insufficient for an agent to use the tool effectively. It does not explain how to specify the action, what 'visible' entails, or provide examples. However, given the schema's completeness, the description meets a minimal threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for parameters are comprehensive (100% coverage), including detailed explanations for filters, sorting, and the action enum. The description itself adds no extra parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List or show'), a resource ('orders'), and additional capabilities (filtering, sorting, pagination). It distinguishes this as a read operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., order-write or other read tools). It does not mention the 'action' parameter's role or when to choose 'list' over 'show', leaving the agent to infer usage from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible tasks for an order. Requires order_number; supports filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| sort | No | Sort fields. Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, name, description, deadline, order_id, sort_order, workflow_step_id, is_public, for_client, is_complete, is_ready, completed_by, due_at, completed_at, created_at, updated_at, tasks.id, tasks.name, tasks.description, tasks.deadline, tasks.order_id, tasks.sort_order, tasks.workflow_step_id, tasks.is_public, tasks.for_client, tasks.is_complete, tasks.is_ready, tasks.completed_by, tasks.due_at, tasks.completed_at, tasks.created_at, tasks.updated_at, workflowStep, order, user, employees. | |
| limit | No | Results per page. Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object. Keys are field names, values are operator objects. Example: {"status":{"$eq":"active"}}. Available fields: id, name, description, deadline, order_id, sort_order, workflow_step_id, is_public, for_client, is_complete, is_ready, completed_by, due_at, completed_at, created_at, updated_at, tasks.id, tasks.name, tasks.description, tasks.deadline, tasks.order_id, tasks.sort_order, tasks.workflow_step_id, tasks.is_public, tasks.for_client, tasks.is_complete, tasks.is_ready, tasks.completed_by, tasks.due_at, tasks.completed_at, tasks.created_at, tasks.updated_at, workflowStep, order, user, employees. | |
| order_number | Yes | Order number. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds the nuance of 'visible tasks,' implying some tasks may be hidden, which is not covered by annotations. It also mentions filtering, sorting, and pagination, giving behavioral context beyond the safety profile. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with the core purpose front-loaded. Zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and the rich schema covering all params, the description is sufficient. It lacks explicit return format details, but with no output schema and the tool being a list operation, the expected response is clear from context. The 'visible' filter is a minor behavioral note not fully elaborated but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented with descriptions. The description's mention of 'filtering, sorting and pagination' maps to existing params but adds no new meaning. Baseline 3 is appropriate since the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('tasks for an order'), clearly distinguishing it from sibling tools like order-read (orders) and order-task-write (writes). The word 'visible' adds precision. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly indicates when to use it (to list tasks for an order) and requires order_number. It does not explicitly mention alternatives or when not to use, but the tool name and purpose make the context obvious. No misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Update an order's status, dates, notes, service, assignments, tags, metadata or linked orders. Collection fields replace their complete lists; omitted fields stay unchanged. Changes can notify clients and trigger integrations.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Internal order note. Max 65535 characters. | |
| tags | No | Tag names or IDs. Replaces current tags when provided. | |
| action | Yes | Action to perform. | |
| status | No | Order status ID. Use numeric IDs, not status names. | |
| service | No | Snapshot service name on the order. Max 255 characters. | |
| date_due | No | Due date/time. YYYY-MM-DD or ISO 8601. | |
| metadata | No | Metadata key/value map. Empty values delete that metadata key. | |
| employees | No | Employee/staff user IDs to assign. Replaces current assignments when provided. | |
| created_at | No | Creation date/time. YYYY-MM-DD or ISO 8601. | |
| service_id | No | Service ID to associate with the order. | |
| date_started | No | Started date/time. YYYY-MM-DD or ISO 8601. | |
| order_number | No | Order number. Required when updating an existing record. | |
| linked_orders | No | Order numbers to link bidirectionally. Replaces current linked orders when provided. | |
| date_completed | No | Completed date/time. YYYY-MM-DD or ISO 8601. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that collection fields replace complete lists and that omitted fields remain unchanged, and that changes can notify clients and trigger integrations. This goes beyond the annotations, which only indicate destructiveHint. It does not explicitly warn about irreversible data loss, but the replace language is explicit enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and target, followed by crucial behavioral notes. No redundant or irrelevant content. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and nested objects, the description gives key operational context: update semantics, replace behavior, and side effects. It does not cover every edge case (e.g., required order_number), but those are in the parameter schema. The description is sufficient for an agent to understand the tool's role and basic constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for each parameter (e.g., 'Replaces current tags when provided', 'Empty values delete that metadata key'). The main description adds little beyond a high-level summary of field categories. It does not introduce new parameter-specific information that isn't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates an order's various fields (status, dates, notes, service, assignments, tags, metadata, linked orders), and distinguishes it from read-only tools. The name and action enum reinforce the write/update purpose. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when updating an existing order) but does not explicitly contrast with alternative tools like order-read. However, the update semantics and mention of side effects (notifications/integrations) provide sufficient guidance. It could be more explicit about not using it for read-only operations, but the name and annotation cover that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show accessible pipeline cards with filtering, sorting and pagination. Item types in filters accept user, company or order.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: pipeline_id, pipeline_stage_id, itemable_type, itemable_id. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: pipeline_id, pipeline_stage_id, itemable_type, itemable_id. | |
| pipeline_item_id | No | Pipeline item id. Required for "show", "remove", and "move". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the word 'accessible', implying permission-scoped results, and clarifies allowed item types in filters. These are useful but modest additions; it does not disclose return format or pagination behavior beyond what schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the core purpose and the most important filter nuance. It is front-loaded with the verb and resource, and every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and a nested filters object, but the schema is rich enough to carry most details. The description omits the distinction between list and show and the requirement for pipeline_item_id in show, both of which are in the schema. Given no output schema, some return-format guidance could help, but the description is adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds one meaningful detail: that item types in filters accept user, company, or order, which clarifies the filter values for itemable_type. This is a small increment over the schema, keeping it at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('List or show accessible pipeline cards') and mentions key capabilities (filtering, sorting, pagination). It does not explicitly distinguish itself from sibling read tools like pipeline-read, but the name and phrasing make the target resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention pipeline-item-write for mutations or pipeline-read for pipeline-level reads. The description implies a read operation but offers no exclusions or alternate routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove or move pipeline cards. add requires pipeline_id, stage_id, itemable_type and itemable_ref; remove requires pipeline_item_id; move requires pipeline_item_id and stage_id. Sales pipelines accept users, companies and deals; production pipelines accept orders. Changes can trigger configured automations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| stage_id | No | Pipeline stage id. Required for "add" and "move". | |
| sort_order | No | Optional 0-based position within the destination stage for "move". Defaults to top. | |
| pipeline_id | No | Pipeline id. Required for "add". | |
| itemable_ref | No | Entity reference. Required for "add". Orders use order number; users, companies and deals use id. | |
| itemable_type | No | Type of entity to add. Required for "add". Sales pipelines accept user, company or deal; production pipelines accept order. For "list" filters, user/company/order/deal aliases are accepted. | |
| pipeline_item_id | No | Pipeline item id. Required for "show", "remove", and "move". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable side-effect context with 'Changes can trigger configured automations,' going beyond the destructiveHint annotation. It could further disclose irreversibility or external consequences, but this is already meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences cover the main operation, per-action requirements, domain constraints, and side effects without redundancy. The key verb phrase is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers all three actions, their parameter dependencies, and entity-type restrictions, which is sufficient for a structured mutation tool with complete schema descriptions. Minor gaps like response behavior or sort_order effects are already handled by the schema or are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enhances this by mapping required parameters to each action and clarifying itemable_ref semantics: orders use order numbers while users, companies, and deals use IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: add, remove, or move pipeline cards, with distinct verbs and a specific resource. It is immediately distinguishable from the sibling pipeline-item-read tool and does not rely on the title alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides action-specific required parameters and pipeline type compatibility, making usage conditions clear. It does not explicitly contrast with pipeline-item-read, but the mutation actions themselves make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show accessible sales or production pipelines and their stages. Lists support filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, name, type, owner_id, is_default, visibility. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, name, type, owner_id, is_default, visibility. | |
| pipeline_id | No | Pipeline id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not burdened with safety disclosure. It adds useful behavioral context by noting 'accessible' pipelines (permission filtering) and that lists support filtering/sorting/pagination. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The purpose is stated first, followed by a summary of list behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with full schema coverage and safety annotations, the description is adequate. However, it lacks details on the return format (no output schema) and does not clarify what 'show' returns versus 'list'. The absence of output schema info leaves the agent guessing about response shape, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters already have clear definitions. The description summarizes list capabilities but does not add meaning beyond the schema. Since the schema handles parameter documentation, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List or show') and a clear resource ('accessible sales or production pipelines and their stages'), and distinguishes between the two actions. It is unambiguous and differentiates the read tool from its write counterpart by its name and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading pipelines but does not explicitly state when to use this tool over alternatives (e.g., pipeline-write for modifications). It mentions list capabilities (filtering, sorting, pagination) but offers no explicit when-not-to-use or guidance for choosing between 'list' and 'show' beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update pipeline structure. Creation requires type, name and stages. Updating stages edits supplied IDs and adds entries without IDs; omitted stages are preserved, not deleted. Cards are managed through pipeline-item-write.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Pipeline name. Required for "create", optional for "update". | |
| type | No | Pipeline type: "sales" or "production". Required for "create". | |
| action | Yes | Action to perform. | |
| stages | No | Pipeline stages. Required for "create" (min 1). For "update": listed stages are edited (with id) or added (without id). | |
| is_default | No | Whether this is the default pipeline for its type. Optional. | |
| visibility | No | Who can see the pipeline: "all_staff" (default), "specific_staff" (see visible_user_ids), or "specific_roles" (see visible_role_ids). | |
| pipeline_id | No | Pipeline id. Required when updating an existing record. | |
| visible_role_ids | No | Role IDs that can see the pipeline. Only used when visibility is "specific_roles". | |
| visible_user_ids | No | Staff user IDs that can see the pipeline. Only used when visibility is "specific_staff". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key side effect: omitted stages are preserved and never deleted, and explicitly routes card changes elsewhere. It does not contradict the destructiveHint annotation, though it does not elaborate on other potential destructive effects or result/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences, front-loaded with the main purpose, and avoids repeating detailed field descriptions already covered by the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter write tool with nested stages, the description covers the most important behavioral context: create requirements, update semantics, stage preservation, and scope separation from pipeline-item-write. It is complete enough for normal use, though it does not touch on return values or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful cross-parameter semantics not present in the schema alone: creation requires type/name/stages, pipeline_id is required for updates, stage id presence means edit vs add, and omitted stages are preserved. This significantly clarifies the nested stage behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair, 'Create or update pipeline structure', and clarifies that cards belong to a separate tool, distinguishing it from pipeline-item-write. The create/update action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when creation is needed (requires type, name, stages), how updates affect stages, and redirects card management to pipeline-item-write. It does not explicitly contrast with pipeline-read, but the write purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current customer-facing Wayfront help-center documentation. Use for product setup, recommended workflows, form/service behavior, limitations, and interface handoffs. Returns excerpts, source links, and document IDs for get-wayfront-doc.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results. Defaults to 5; maximum 10. | |
| query | Yes | Natural-language question about using or configuring Wayfront. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. Description adds that it returns excerpts, source links, and document IDs, which is consistent and provides useful output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences efficiently cover purpose, usage scenarios, and output format. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description is complete: it communicates what it searches, why to use it, and what it returns, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions fully cover both parameters: query as a natural-language question, limit with default and max. The description adds no extra parameter details beyond the schema, so baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Search' and resource 'customer-facing Wayfront help-center documentation'. Distinguishes from sibling get-wayfront-doc by noting document IDs are returned for that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists specific use cases (product setup, workflows, behavior, limitations, handoffs) and implies the companion tool for retrieval. Could be more explicit about when not to use, but the given topics are sufficient for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show services, or get_task_templates for a service's current reusable checklist and template IDs. Lists support filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, intake_form_id, is_taxable, name, description, image, recurring, price, max_active_requests, pretty_price, currency, f_price, f_period_l, f_period_t, r_price, r_period_l, r_period_t, recurring_action, multi_order, request_orders, option_categories, option_variants, deadline, public, sort_order, braintree_plan_id, group_quantities, folder_id, metadata, hoth_product_key, hoth_package_name, created_at, updated_at, provider_id, provider_service_id, deleted_at, services.id, services.intake_form_id, services.is_taxable, services.name, services.description, services.image, services.recurring, services.price, services.max_active_requests, services.pretty_price, services.currency, services.f_price, services.f_period_l, services.f_period_t, services.r_price, services.r_period_l, services.r_period_t, services.recurring_action, services.multi_order, services.request_orders, services.option_categories, services.option_variants, services.deadline, services.public, services.sort_order, services.braintree_plan_id, services.group_quantities, services.folder_id, services.metadata, services.hoth_product_key, services.hoth_package_name, services.created_at, services.updated_at, services.provider_id, services.provider_service_id, services.deleted_at, orders, invoice_items, addons, parent_services, folder, reseller_provider, tasks, workflowSteps, intakeForm, onboardingForms, addon_orders, getFieldsAttribute, employees, audits, morphMetadata, media, logs. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, intake_form_id, is_taxable, name, description, image, recurring, price, max_active_requests, pretty_price, currency, f_price, f_period_l, f_period_t, r_price, r_period_l, r_period_t, recurring_action, multi_order, request_orders, option_categories, option_variants, deadline, public, sort_order, braintree_plan_id, group_quantities, folder_id, metadata, hoth_product_key, hoth_package_name, created_at, updated_at, provider_id, provider_service_id, deleted_at, services.id, services.intake_form_id, services.is_taxable, services.name, services.description, services.image, services.recurring, services.price, services.max_active_requests, services.pretty_price, services.currency, services.f_price, services.f_period_l, services.f_period_t, services.r_price, services.r_period_l, services.r_period_t, services.recurring_action, services.multi_order, services.request_orders, services.option_categories, services.option_variants, services.deadline, services.public, services.sort_order, services.braintree_plan_id, services.group_quantities, services.folder_id, services.metadata, services.hoth_product_key, services.hoth_package_name, services.created_at, services.updated_at, services.provider_id, services.provider_service_id, services.deleted_at, orders, invoice_items, addons, parent_services, folder, reseller_provider, tasks, workflowSteps, intakeForm, onboardingForms, addon_orders, getFieldsAttribute, employees, audits, morphMetadata, media, logs. | |
| service_id | No | Service id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint and destructiveHint annotations; it only describes read operations and does not imply side effects. It does not add extra behavioral details like auth or rate limits, but the annotations already cover the core read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that enumerates the valid actions and highlights the key list capability. It avoids unnecessary prose and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description covers the main operations and the list capabilities. It could be slightly more explicit about the differing outputs of 'show' vs 'get_task_templates', but the action enum and parameter descriptions fill most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for most parameters, including the action enum, filter example, and sortable fields. The description adds little beyond those schema details, and the phrase 'Purity filter object' appears to be a typo that could slightly confuse, though the example mitigates it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the three read actions ('list', 'show', 'get_task_templates') and the resource type (services). It is readily distinguishable from the sibling service-write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that list supports filtering, sorting, and pagination, but it does not explicitly say when to use this read tool versus the sibling service-write alternative. Action-specific requirements are left to the parameter descriptions rather than stated as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 employee/staff user IDs to assign to this service. | |
| 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. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly warns that sync_task_templates overwrites and deletes omitted templates, that relationship collections replace full lists, and that pricing/recurrence changes affect future delivery. This goes beyond the destructiveHint annotation by specifying exactly which operations are destructive and how to avoid unintended deletions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is front-loaded with key warnings, and parameter descriptions are dense but relevant. The overall length is justified by 28 parameters, with minimal fluff, though a few descriptions restate information already implied by the parameter name or type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers conditional fields, required-vs-optional behavior for create and update, destructive semantics, unit conversions, and relationship replacement rules. Even without an output schema, an agent has enough context to invoke the tool correctly and avoid common mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter is described, and many descriptions add crucial semantics not inferable from the schema alone, such as deadline being in hours, recurring enum meanings, conditional requirements for recurring=2, folder_id null-versus-omitted behavior, and the full-replacement behavior of task_templates. This far exceeds the baseline expected from full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool creates or updates services and syncs task templates, clearly identifying the resource and actions. It also distinguishes itself from read-oriented tools by instructing the agent to fetch task templates before syncing, making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage rules: call get_task_templates before sync_task_templates and retain IDs to avoid deletion, convert deadlines to hours, and understand that relationship collections replace full lists. It could more explicitly contrast with service-read for ordinary reads, but the write-versus-read distinction is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View current workspace branding and business settings.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and non-open-world behavior. The description adds no further side-effect or behavioral detail beyond the obvious 'View' action, so it meets but does not exceed the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, redundant wording, or unnecessary detail. It is well-structured and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description gives enough context about what is being viewed. It could slightly improve by mentioning that no other actions are supported, but the enum already conveys this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'action' has full schema coverage with an enum of ['view'] and a generic description. The tool description adds no additional semantic detail beyond what the schema already makes clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function with a specific verb ('View') and resource ('current workspace branding and settings'), and it is easily distinguished from the sibling 'settings-write' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only usage but does not explicitly state when to prefer this tool over alternatives such as 'settings-write' or 'workspace-info'. No direct when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update workspace name, colors, timezone, contact link, currency, business information, email sender display name and logos. Logo URLs must be public images. Does not connect Stripe, set a custom domain or sending email address, or switch live mode.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| currency | No | Default currency as an uppercase ISO-4217 code, e.g. "USD". For "update". | |
| logo_url | No | Public URL of a PNG/JPEG/GIF logo to import. For "update". | |
| timezone | No | IANA timezone, e.g. "America/New_York". For "update". | |
| from_name | No | Sender name shown on client order/ticket message-reply notification emails. (General transactional emails use the workspace name.) For "update". | |
| site_name | No | Workspace name (max 64). For "update". | |
| accent_color | No | Brand accent color as hex, e.g. "#387FFF". For "update". | |
| contact_link | No | Public contact URL shown to clients. For "update". | |
| business_info | No | Business name/address block shown on invoices. For "update". | |
| primary_color | No | Brand primary color as hex, e.g. "#1A1E34". For "update". | |
| logo_inverse_url | No | Public URL of a PNG/JPEG/GIF inverse (light) logo for dark sidebars. For "update". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate mutation. It adds useful constraints about logo URLs and excluded actions, but does not detail potential overwrite or irreversible side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that lists the affected fields and includes important constraints and exclusions without unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple update semantics and full schema parameter descriptions, the description provides enough context for an agent to invoke the tool correctly. It includes practical exclusions and URL constraints; a return-value description is not necessary since no output schema is declared.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with examples and constraints, so the baseline is 3. The description reinforces the logo URL requirement and adds exclusion context, but does not significantly extend the parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and enumerates the exact workspace settings affected (name, colors, timezone, contact link, currency, business information, email sender name, logos). This clearly distinguishes it from the sibling settings-read tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for modifying workspace settings, and explicitly lists what it does not do (connect Stripe, set custom domain/sending email, switch live mode). This gives useful exclusionary guidance, though it does not explicitly say 'use settings-read to view settings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View notification settings and available events for an already-connected Slack workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with readOnlyHint and destructiveHint annotations, confirming no side effects. It does not add details about return format or error conditions, but the annotations already cover the key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose with no unnecessary verbiage. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read operation. It specifies the subject (notification settings and events) and the scope (already-connected Slack workspace). Absence of an output schema is acceptable given the tool's simplicity, though it could clarify the exact return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'action' has an enum of ['view'] with a generic description 'Action to perform.' While the schema fully specifies the allowed value, the description adds minimal context beyond what is already evident from the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: viewing notification settings and available events for a connected Slack workspace. It distinguishes it from the sibling slack-write tool by focusing on read-only actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for read-only inspection of Slack configuration. It does not explicitly state when to avoid using it, but the read-only nature is obvious from the verb 'view' and the annotation, making it sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update notification events and channels for an already-connected Slack workspace. Only listed events change; others remain unchanged. Slack must be connected and licensed. Connecting Slack requires the Wayfront interface.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| events | No | Per-event notification settings to change. Only the listed events are updated; others are left unchanged. Required for "update". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutating nature is known. The description adds valuable behavioral context beyond that: it specifies the partial update semantics (only listed events change) and the dependency on connection/licensing, which are not captured in annotations. This helps an agent anticipate side effects and failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, behavior, and prerequisite. It is front-loaded with the main action, then clarifies scope and requirements. Every sentence earns its place without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with two parameters (one required) and no output schema, the description covers the essential aspects: what it updates, how partial updates work, and prerequisites. It does not mention error handling or post-update confirmation, but those are not typically required for a mutation tool. The annotations already signal destructiveness, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both 'action' and 'events' (including nested event fields). The description does not add new parameter-level meaning; it only reiterates the partial update behavior that the schema already hints at via the events description. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'notification events and channels' for an already-connected Slack workspace, making its purpose unambiguous. It also adds the partial-update behavior ('Only listed events change; others remain unchanged') which distinguishes it from a full overwrite and implicitly from the read sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (updating Slack notifications for a connected workspace) and prerequisites (Slack must be connected and licensed, connecting requires the Wayfront interface). It does not explicitly name alternatives like slack-read, but the context is sufficient for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query subscriptions. Actions: "list" — query subscriptions with filtering, sorting, pagination. "show" — get a single subscription by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, user_id, number, name, status, processor_id, current_period_end, canceled_at, created_at, updated_at, deleted_at, reseller_processor_key, subscriptions.id, subscriptions.user_id, subscriptions.number, subscriptions.name, subscriptions.status, subscriptions.processor_id, subscriptions.current_period_end, subscriptions.canceled_at, subscriptions.created_at, subscriptions.updated_at, subscriptions.deleted_at, subscriptions.reseller_processor_key, invoice, user, invoices, payments, subscription_services, orders, audits, collaborators, logs. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, user_id, number, name, status, processor_id, current_period_end, canceled_at, created_at, updated_at, deleted_at, reseller_processor_key, subscriptions.id, subscriptions.user_id, subscriptions.number, subscriptions.name, subscriptions.status, subscriptions.processor_id, subscriptions.current_period_end, subscriptions.canceled_at, subscriptions.created_at, subscriptions.updated_at, subscriptions.deleted_at, subscriptions.reseller_processor_key, invoice, user, invoices, payments, subscription_services, orders, audits, collaborators, logs. | |
| subscription_id | No | Subscription id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the action breakdown (list vs show) but does not disclose additional behavioral traits such as return format, pagination details, or any side effects. It does not contradict the annotations, but the added value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The purpose is front-loaded, and the action breakdown is immediately useful. Every word earns its place, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and nested objects but no output schema, the description is adequate but thin. It does not describe the response shape, pagination behavior beyond schema defaults, or any constraints on usage. The schema covers parameter details, but the description leaves return-value expectations implicit, which is acceptable for a read-only tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, including detailed parameter explanations (e.g., sort fields, filters object example, defaults). The description adds no parameter-specific meaning beyond what the schema already provides, so it meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'query' with the resource 'subscriptions' and distinguishes the two actions: 'list' for filtered/sorted/paginated queries and 'show' for a single subscription by ID. This is specific and unambiguous, leaving no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the action names: use 'list' for multiple subscriptions with filtering, 'show' for one by ID. However, it does not explicitly state when to use this tool over alternatives or provide exclusions. Since it is the only subscription-specific tool among siblings, the context is clear, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workspace tags and their IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already communicate safety, and the description is consistent with them. However, the description adds little beyond the annotation, such as pagination, ordering, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is immediately understandable and front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description adequately states what is returned (tags and IDs). It is complete enough for basic usage, though it omits potential details like ordering or filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with an enum and description, so coverage is high. The tool description reinforces that 'action' is 'list', but it does not add substantial parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('workspace tags'), and the expected output ('their IDs'). It is specific and easily distinguished from sibling tools like tag-write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only usage by saying 'List', and the annotation reinforces this, but it does not explicitly mention when to use this tool versus alternatives such as tag-write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workspace tag. Requires name and tag-management permission. Optional sort_order controls display order.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Tag name. Required for "create". | |
| action | Yes | Action to perform. | |
| sort_order | No | Display order of the tag. Optional for "create". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only and destructive hints are already provided by annotations, so the description only needs to add context. It proactively mentions the required permission and the fact that this is a create operation, which is useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant or filler content. It front-loads the primary purpose and then provides key usage details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for the simple create operation and covers permission and key parameters. It does not describe return values, but no output schema is present and this is not essential for deciding when or how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter has a schema description, and the tool description adds practical meaning: name is required for creation, sort_order is optional and controls display order, and action is fixed to 'create'. This clarifies how to actually invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a workspace tag, using a specific verb and resource. This distinguishes it from tag-read and other write tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies required inputs (name) and the required permission (tag-management). It does not explicitly differentiate from tag-read, but the create action and resource make the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage team members and roles. Actions: "create" — invite a new staff member (emails them their login). "update" — reassign an existing staff member to a different role (changes their permissions). "create_role" — create a new permission set / role (admin only). Reading team members stays in the team query tool. You can only assign or create roles whose permissions do not exceed your own, and only the workspace owner can manage admin accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the new role. Required for "create_role". | |
| No | New staff member's email address. Required for "create". | ||
| forms | No | Permission level 0-9 for forms. For "create_role". | |
| action | Yes | "create" invites a staff member; "update" reassigns a staff member's role; "create_role" creates a new permission set. | |
| name_f | No | First name. Optional for "create". | |
| name_l | No | Last name. Optional for "create". | |
| clients | No | Permission level 0-9 for clients. For "create_role". | |
| coupons | No | Permission level 0-9 for coupons. For "create_role". | |
| role_id | No | Role (permission set) ID to assign. Required for "create" and "update". Use the team query tool to discover role IDs. | |
| user_id | No | Existing staff member's user ID whose role to change. Required for "update". | |
| services | No | Permission level 0-9 for services. For "create_role". | |
| messaging | No | Permission level 0-9 for messaging. For "create_role". | |
| affiliates | No | Permission level 0-9 for affiliates. For "create_role". | |
| order_access | No | Permission level 0-9 for order_access. For "create_role". | |
| rank_tracking | No | Permission level 0-9 for rank_tracking. For "create_role". | |
| settings_logs | No | Grant access to settings_logs. For "create_role". | |
| settings_tags | No | Grant access to settings_tags. For "create_role". | |
| settings_team | No | Grant access to settings_team. For "create_role". | |
| ticket_access | No | Permission level 0-9 for ticket_access. For "create_role". | |
| welcome_email | No | Whether to email the new staff member their login. Defaults to true. For "create". | |
| invoice_access | No | Permission level 0-9 for invoice_access. For "create_role". | |
| settings_emails | No | Grant access to settings_emails. For "create_role". | |
| settings_orders | No | Grant access to settings_orders. For "create_role". | |
| dashboard_access | No | Permission level 0-9 for dashboard_access. For "create_role". | |
| order_management | No | Permission level 0-9 for order_management. For "create_role". | |
| settings_company | No | Grant access to settings_company. For "create_role". | |
| settings_modules | No | Grant access to settings_modules. For "create_role". | |
| settings_sidebar | No | Grant access to settings_sidebar. For "create_role". | |
| settings_tickets | No | Grant access to settings_tickets. For "create_role". | |
| settings_accounts | No | Grant access to settings_accounts. For "create_role". | |
| settings_language | No | Grant access to settings_language. For "create_role". | |
| settings_messages | No | Grant access to settings_messages. For "create_role". | |
| settings_payments | No | Grant access to settings_payments. For "create_role". | |
| ticket_management | No | Permission level 0-9 for ticket_management. For "create_role". | |
| invoice_management | No | Permission level 0-9 for invoice_management. For "create_role". | |
| settings_dashboard | No | Grant access to settings_dashboard. For "create_role". | |
| settings_templates | No | Grant access to settings_templates. For "create_role". | |
| time_tracking_manage | No | Grant time-tracking management. For "create_role". | |
| settings_integrations | No | Grant access to settings_integrations. For "create_role". | |
| settings_saved_replies | No | Grant access to settings_saved_replies. For "create_role". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects for each action: 'emails them their login' for create, 'changes their permissions' for update, and 'creates a new permission set' for create_role. It also mentions the constraint that roles cannot exceed your own permissions. While it doesn't dwell on potential destructive consequences, the actions are inherently non-destructive (no delete) and the description covers the key impacts. No contradiction with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using three sentences to cover all actions and key constraints. While it could be formatted with bullet points for clarity, it remains efficient and avoids redundancy. No filler or unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for correct usage: it identifies the three actions, points to the team query tool for reading and role IDs, states admin/owner restrictions, and clarifies the welcome email default. Given the tool's complexity (40 parameters), the description covers the essential operational context without needing to explain every permission field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every parameter has a description with relevant 'For "action"' qualifiers. The description text adds no extra parameter-level detail beyond what the schema already provides, but it does reinforce the role_id lookup via the team query tool. Baseline 3 applies because schema fully covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose ('Manage team members and roles') and enumerates the three distinct actions (create, update, create_role) with specific verbs. It also distinguishes itself from the read side by noting that reading team members belongs in the team query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives: reading team members is delegated to the team query tool, and role IDs are to be discovered via that query tool. Also states usage restrictions (admin-only for create_role, workspace-owner-only for admin accounts) and notes the welcome_email default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query team members. Actions: "list" — query team members with filtering, sorting, pagination. "show" — get a single team member by user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, email, role, role_id, accounts.id, status_id, managers, manager_id, pipelineItems, optin, created_at, updated_at. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, email, role, role_id, accounts.id, status_id, managers, manager_id, pipelineItems, optin, created_at, updated_at. Role filter key is "role_id" (numeric IDs, not string names): 1=Admin, 2=Manager, 3=Contractor. | |
| user_id | No | User id. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral detail beyond what the schema already exposes (action enum). It does not disclose any rate limits, permissions, or response characteristics beyond the read-only nature, which is already known from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The core purpose is front-loaded, and the action breakdown is immediately clear. Structure is exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with complete schema documentation and no output schema, the description covers the two actions and their parameter associations sufficiently. It could mention that it is the read-only counterpart to team-management-tool, but that is not essential for correct invocation. Overall, the agent has enough to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a high-level mapping: 'filtering, sorting, pagination' aligns with filters, sort, page, and limit; 'get a single team member by user ID' aligns with user_id. However, this is mostly a paraphrase of the schema descriptions and adds little new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query') and resource ('team members'), and immediately distinguishes two actions with distinct purposes ('list' with filtering/sorting/pagination, 'show' with user ID lookup). This clearly identifies the tool's function and separates it from write-oriented siblings like team-management-tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention team-management-tool or any other sibling, nor does it provide exclusions or conditions. The agent must infer from the action names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workspace Twig templates, optionally filtered by name_prefix or search, or show one template's full source.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| search | No | Search templates by name or content for "list". Can be combined with name_prefix. | |
| name_prefix | No | Filter templates by name prefix for "list" (e.g. "email.", "public.", "custom."). Use the normalized name without the "portal." prefix. | |
| template_name | No | Template name (e.g. "email.invoice_paid") or a raw design-scoped db_name. Required for "show". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation and clearly states that it lists templates or returns full source, implying no destructive behavior. It adds useful context about the template type and source exposure, though it does not mention potential output size or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys both capabilities and optional filters. There is no redundant wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description gives enough context about what actions are available and what the 'show' action returns. It does not describe the list output format in detail, but the purpose is clear and the parameter schema fills most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with clear descriptions, and the tool description restates the action-based filtering and show behavior. Since schema coverage is 100%, the description adds moderate context but does not significantly deepen parameter meaning beyond what is already provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as workspace Twig templates and states the two supported actions: listing and showing full source. It does not explicitly differentiate itself from template-write or other read tools, but the action set and resource are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains filtering and the show action, but it does not say when to prefer this tool over sibling tools such as template-write or other read tools. There is no explicit 'use this for read-only operations' guidance in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update or reset workspace Twig templates used by client pages and outgoing emails. update replaces the full source, so read template-read action show first and preserve the intended content. Invalid Twig syntax is rejected. reset removes the override; resetting a custom page permanently deletes it. No version history is available.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Full replacement Twig source for "update". Read template-read action show first and preserve the intended content. | |
| action | Yes | Action to perform. | |
| is_active | No | Whether the template is enabled for "update". Omit to keep its current value. Emails with is_active false are not sent. | |
| template_name | No | Template name (e.g. "email.invoice_paid") or a raw design-scoped db_name. Required for "update" and "reset". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses destructive behavior by stating that reset permanently deletes a custom page and that no version history exists. It also notes validation behavior (invalid Twig syntax rejected), consistent with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core purpose first and then adding necessary warnings and usage guidance in four sentences. Every sentence contributes operational or safety-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive action and lack of an output schema, the description provides the essential context: intended use, required read-before-write flow, reset consequences, syntax validation, and absence of version history. It is complete enough for an agent to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of all parameters with detailed descriptions, including action enum semantics, data as full replacement source, template_name requirements, and is_active behavior. The description text itself does not add additional parameter-level meaning beyond that schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates or resets workspace Twig templates used by client pages and emails, making its purpose and resource type explicit. It also distinguishes itself from template-read and other write tools by naming update and reset actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit instructions to read template-read first before updating to preserve intended content, and explains when to use update versus reset. It also warns that resetting a custom page permanently deletes it and that invalid Twig syntax is rejected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List messages for a visible support ticket, including whether each message is staff-only. Requires ticket_number; supports filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| sort | No | Sort fields. Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media. | |
| limit | No | Results per page. Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object. Keys are field names, values are operator objects. Example: {"status":{"$eq":"active"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media. | |
| ticket_number | Yes | Ticket number. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior; the description adds useful context about visibility (only visible tickets) and staff-only content. It does not add richer behavioral detail like auth requirements, output shape, or how staff-only messages are treated, so it stays at the baseline-plus level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the action, scope, and capabilities with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with six schema-described parameters and no output schema, the description covers the essential preconditions, scope, and capabilities. A slightly richer mention of return structure or why visibility matters would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented in the input schema. The description adds only that ticket_number is needed and that filtering/sorting/pagination are supported, which adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: "List messages for a visible support ticket", and adds the staff-only distinction. This clearly separates it from read/list siblings and from the write counterpart by focusing on read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the hard prerequisite that ticket_number is required and says filtering, sorting, and pagination are supported, which implies when this tool is appropriate. It does not explicitly tell the agent when to prefer this over ticket-message-write or order-message-read, leaving destination decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a message to a support ticket. Requires ticket_number and message. staff_only defaults to true; false can notify the client. The normal notification, webhook and broadcast pipeline runs; sent messages cannot be recalled.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| message | No | Message body (plain text or HTML). Required for "create" action. | |
| staff_only | No | If true, message is only visible to staff. Defaults to true for "create". | |
| ticket_number | Yes | Ticket number. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: messages cannot be recalled, and the normal notification, webhook, and broadcast pipeline runs. This is consistent with destructiveHint and readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and direct, conveying essential behavior and side effects in three sentences without unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs and side effects, but since there is no output schema, it does not indicate what the tool returns on success or failure. This leaves some ambiguity in expected outcomes for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema, and the description adds useful context for staff_only and message. However, there is an inconsistency: the schema lists message as not required while the description says it is required for the only allowed action value, which could confuse an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Post') and object ('a message to a support ticket'), making it easy to distinguish from related read/write ticket tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains required inputs and side effects, but it does not explicitly contrast with sibling tools such as ticket-message-read or ticket-write, or state when this tool should be preferred over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or show visible support tickets with filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for "list". Default 1. | |
| sort | No | Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. | |
| limit | No | Results per page for "list". Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is "status" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed. | |
| ticket_number | No | Ticket number. Required for "show" actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'visible' scope and the two access modes (list/show), but it does not clarify what 'visible' means or describe response behavior. This adds some context beyond annotations but leaves meaningful ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase conveys useful information: the resource, the two operations, the visibility scope, and the supported capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and covers parameter semantics, including the ticket_number requirement for 'show' and filter syntax examples. The description plus schema gives an agent enough to invoke the tool correctly. Minor gaps are the undefined meaning of 'visible' and the lack of any note about the returned payload shape, since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and parameters like action, filters, sort, limit, page, and ticket_number are already well documented. The description's mention of filtering, sorting, and pagination simply mirrors the schema rather than adding new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('List or show visible support tickets') and names the core capabilities: filtering, sorting, and pagination. It clearly distinguishes this read tool from siblings like ticket-write and ticket-message-read by scope and action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for read-only ticket access through 'List or show visible support tickets', but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There are no exclusions or routing cues beyond the obvious read/write contrast with ticket-write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update support tickets. Creation can send an initial client-facing message. Updates can replace assignments, tags and metadata. Sent messages cannot be recalled.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Ticket note. Empty HTML-only values are stored as an empty string. Max 255 characters. | |
| tags | No | Tag names or IDs. Replaces current tags when provided. | |
| order | No | Order number to associate with the ticket. Pass a number to associate; omit to leave unchanged. Dissociation is not supported via this field. | |
| action | Yes | Action to perform. | |
| status | No | Ticket status ID. Use numeric IDs, not status names. | |
| message | No | Optional first client-facing message to post on the new ticket in the same "create" call. Requires the workspace to be on a paid plan with a configured custom domain; omit it to create the ticket without messaging the client. | |
| subject | No | Ticket subject. Max 65535 characters. | |
| user_id | No | Client user ID the ticket belongs to. Required for "create". | |
| metadata | No | Metadata key/value map. Empty values delete that metadata key. | |
| employees | No | Employee/staff user IDs to assign. Replaces current assignments when provided. | |
| ticket_number | No | Ticket number. Required when updating an existing record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, readOnlyHint), the description adds behavioral context: 'Sent messages cannot be recalled' and 'Updates can replace assignments, tags and metadata.' This warns about irreversible actions and replacement semantics, which is valuable for agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of three short sentences that capture the core functionality, additional capabilities, and a warning. No redundant or vague language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and nested objects, the description provides sufficient context by outlining the primary operations (create/update) and side effects. It does not explain output or error handling, but the absence of an output schema lowers the need for that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add parameter-level details; it relies on the schema descriptions, which are already comprehensive (100% coverage). Since the schema covers all parameters with meaningful descriptions, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create or update support tickets.' It distinguishes itself from related tools like ticket-read and ticket-message-write by focusing on ticket creation/update and mentioning the first client message. The additional note about messages not being recalled reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating or updating tickets but does not explicitly compare to alternatives. It does not mention when to use ticket-message-write for subsequent messages or ticket-read for viewing tickets. While the intent is clear, explicit guidance would improve selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CRM activities for a client. Requires user_id; supports filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| sort | No | Sort fields. Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, deal, author, assignee, completedBy, audits. | |
| limit | No | Results per page. Default 20, max 100. | |
| action | Yes | Action to perform. | |
| filters | No | Purity filter object. Keys are field names, values are operator objects. Example: {"status":{"$eq":"active"}}. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, deal, author, assignee, completedBy, audits. | |
| user_id | Yes | User id. Required for all actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it lists activities and mentions filtering/sorting/pagination, which are parameter-related rather than behavioral traits. It adds no extra context about outcomes, data scope, or side effects, but it is consistent with the annotations. Given the annotations lower the bar, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('List CRM activities') and then packs essential details (required parameter and supported features) without any filler. Every word contributes, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, a nested object, and no output schema. The description does not mention the response format, default ordering, or any limitations, which an agent might need since the output schema is absent. It is adequate for a simple list operation but leaves gaps given the complexity of the filter and sort options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having its own description. The tool description adds only a general statement about requiring user_id and supporting filtering/sorting/pagination, which does not deepen understanding of specific parameters beyond the schema. Baseline 3 applies since the schema carries the responsibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('CRM activities') and clearly indicates the scope ('for a client'). It distinguishes itself from sibling tools like 'user-activity-write' and other read tools by naming the exact object being operated on. The requirement of user_id is stated upfront, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite (user_id) but provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or alternative sibling tools. An agent would not know if this is the right tool for a given task compared to other read tools like client-read or ticket-read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create CRM activity entries or complete scheduled activities. Requires user_id. create requires content; complete requires activity_id. Entries and completions are attributed to the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. | |
| content | No | Activity content/notes (plain text, max 10000 chars). Required for "create" action. | |
| user_id | Yes | User id. Required for all actions. | |
| activity_id | No | Activity ID. Required for "complete". | |
| assigned_to | No | Optional staff user ID to assign. Only used when scheduled_at is provided. | |
| scheduled_at | No | Optional future scheduled date/time for "create" (ISO 8601). If omitted, the activity is logged as completed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals modification, and the description adds useful context about attribution to the authenticated user and the create-vs-complete behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two sentences that cover the main actions, required fields, and attribution. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema and annotations, the description is adequately complete for a write tool with conditional actions. It covers the primary behaviors and requirements without needing to explain return values since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high, but the description reinforces conditional requirements and adds the semantic detail that entries and completions are attributed to the authenticated user. This goes slightly beyond the existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates CRM activity entries or completes scheduled activities, with a specific verb and resource. This distinguishes it from user-activity-read and other sibling write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides actionable usage guidance by specifying that create requires content, complete requires activity_id, and user_id is always required. It implies when to use each action, though it does not explicitly call out the read alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured outbound workspace webhooks without contacting their destinations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint true and destructiveHint false; description adds that it does not contact destinations, providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no redundancy; clearly structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple list operation; no missing critical information like side effects (explicitly noted) or required input (action=list).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (one 'action' parameter with description), but tool description does not add further meaning to the parameter; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists configured outbound workspace webhooks, a read operation, which distinguishes it from webhook-write and other write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates use for listing webhooks, but does not explicitly contrast with alternatives like webhook-write; still clear from the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, enable, disable or delete outbound webhooks. create requires a destination URL and event slugs and creates one webhook per event. Active webhooks send workspace data to that URL. Other actions require webhook_id. See the Wayfront webhook API documentation: https://wayfront.com/help/knowledgebase/webhooks.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Destination URL (http/https) that will receive the event POSTs. Required for "create". | |
| note | No | Optional label/description for the webhook. For "create". | |
| action | Yes | Action to perform. | |
| events | No | One or more namespaced event slugs to subscribe, e.g. ["order.created", "invoice.paid"]. Required for "create". One webhook row is created per event. | |
| is_active | No | Whether the webhook is active on creation. Defaults to true. For "create". | |
| webhook_id | No | Webhook ID. Required for "enable", "disable", and "delete". Use "list" to discover IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds behavioral details: creates one webhook per event, active webhooks send workspace data to the URL, and other actions require webhook_id. This gives the agent a clearer picture of side effects without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action list. Every sentence adds value: action overview, per-action requirements, and a documentation link. No superfluous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions with different parameter requirements), the description covers all necessary context: what each action does, required parameters, and a link to more detailed docs. It does not explain output or error behavior, but no output schema exists and this is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover all parameters (100% coverage), including the one-row-per-event note for events and the default for is_active. The description repeats some of this information (create requires URL/events, other actions need webhook_id) but adds no new semantic value beyond what the schema provides. Baseline 3 applies given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's four actions (create, enable, disable, delete) and the resource (outbound webhooks). It distinguishes from the sibling webhook-read tool by focusing on mutations, and the verb list is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions for each action: create requires a destination URL and event slugs, enable/disable/delete require webhook_id. It notes the one-webhook-per-event behavior and points to external documentation. It does not explicitly name alternatives (e.g., webhook-read for reads), but the mutation focus is clear enough for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the connected Wayfront workspace and authenticated staff account, and summarize the role-level actions available through MCP. Use this when workspace identity, permissions, or connection type matters. Record visibility and some actions remain subject to module and record-specific policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, non-destructive, and not open-world. The description adds useful behavioral context about summarizing role-level actions and subjection to policies, without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant or vague wording. It front-loads the core function and then provides usage guidance and caveats efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers what it does, when to use it, and important limitations. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to explain parameter behavior. The description appropriately focuses on the tool's purpose and output rather than input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies the connected Wayfront workspace and authenticated staff account, and summarizes role-level actions. This is a specific, distinct purpose compared to sibling tools focused on records, messages, or settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when workspace identity, permissions, or connection type matters,' providing direct guidance on when to select this tool over siblings. The caveat about record visibility and policies adds practical context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
invoice-tool2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. Status filter key is \"status\" (numeric IDs, not string names): 0=abandoned, 1=paid, 6=partially_paid, 5=payment_pending, 8=refund, 4=refunded, 3=unpaid, 7=void."New value: +"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, deal, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. Status filter key is \"status\" (numeric IDs, not string names): 0=abandoned, 1=paid, 6=partially_paid, 5=payment_pending, 8=refund, 4=refunded, 3=unpaid, 7=void."Input schema / properties / sort / descriptionPrevious value: -"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs."New value: +"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, deal, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs."pipeline-item-write3 fields changedInput schema / properties / itemable_ref / descriptionPrevious value: -"Entity reference. Required for \"add\". Orders use order number; users and companies use id."New value: +"Entity reference. Required for \"add\". Orders use order number; users, companies and deals use id."Input schema / properties / itemable_type / descriptionPrevious value: -"Type of entity to add. Required for \"add\". Sales pipelines accept user or company; production pipelines accept order. For \"list\" filters, user/company/order aliases are accepted."New value: +"Type of entity to add. Required for \"add\". Sales pipelines accept user, company or deal; production pipelines accept order. For \"list\" filters, user/company/order/deal aliases are accepted."Input schema / properties / itemable_type / enumPrevious value: -[
- "user",
- "company",
- "order"
-]New value: +[
+ "user",
+ "company",
+ "order",
+ "deal"
+]ticket-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is \"status\" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed."New value: +"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is \"status\" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed."Input schema / properties / sort / descriptionPrevious value: -"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications."New value: +"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications."user-activity-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, deal, author, assignee, completedBy, audits."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, deal, author, assignee, completedBy, audits."invoice-tool2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, number_prefix, user_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. Status filter key is \"status\" (numeric IDs, not string names): 0=abandoned, 1=paid, 6=partially_paid, 5=payment_pending, 8=refund, 4=refunded, 3=unpaid, 7=void."New value: +"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs. Status filter key is \"status\" (numeric IDs, not string names): 0=abandoned, 1=paid, 6=partially_paid, 5=payment_pending, 8=refund, 4=refunded, 3=unpaid, 7=void."Input schema / properties / sort / descriptionPrevious value: -"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, number_prefix, user_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs."New value: +"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, number_prefix, user_id, deal_id, status, date_due, date_paid, billing_at, credit, subtotal_converted, total_converted, subtotal, total, tax, tax_name, tax_percent, currency, reason, note, user_data, ip_address, user_agent, sender_address, recurring, recurring_generated, coupon_id, transaction_id, stripe_invoice_id, billing_reason, payment_intent_id, loc_confirm, paysys, stripe_payment_mode, allowed_payment_integrations, partial_payment, employee_id, created_at, updated_at, pretty_number, invoices.id, invoices.number, invoices.number_prefix, invoices.user_id, invoices.deal_id, invoices.status, invoices.date_due, invoices.date_paid, invoices.billing_at, invoices.credit, invoices.subtotal_converted, invoices.total_converted, invoices.subtotal, invoices.total, invoices.tax, invoices.tax_name, invoices.tax_percent, invoices.currency, invoices.reason, invoices.note, invoices.user_data, invoices.ip_address, invoices.user_agent, invoices.sender_address, invoices.recurring, invoices.recurring_generated, invoices.coupon_id, invoices.transaction_id, invoices.stripe_invoice_id, invoices.billing_reason, invoices.payment_intent_id, invoices.loc_confirm, invoices.paysys, invoices.stripe_payment_mode, invoices.allowed_payment_integrations, invoices.partial_payment, invoices.employee_id, invoices.created_at, invoices.updated_at, invoices.pretty_number, audits, subscription, subscription_payment, user, invoice_items, orders, invoice_sender_address, billing_address, coupon, employee, clientTags, logs."user-activity-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, deal_id, author_id, content, scheduled_at, completed_at, completed_by, assigned_to, created_at, updated_at, activities.id, activities.user_id, activities.deal_id, activities.author_id, activities.content, activities.scheduled_at, activities.completed_at, activities.completed_by, activities.assigned_to, activities.created_at, activities.updated_at, user, author, assignee, completedBy, audits."company-write2 fields changedInput schema / properties / new_owner_client_id / descriptionPrevious 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."Input schema / properties / owner_client_id / descriptionPrevious 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."company-write1 field changedInput schema / properties / share_existing_subscriptionsAdded 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"
+}company-write2 fields changedInput schema / properties / action / enumPrevious value: -[
- "create",
- "update",
- "add_member",
- "update_member",
- "remove_member"
-]New value: +[
+ "create",
+ "update",
+ "add_member",
+ "update_member",
+ "remove_member",
+ "delete"
+]Input schema / properties / company_id / descriptionPrevious 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\"."client-write26 fields changedInput schema / properties / action / enumPrevious value: -[
- "create"
-]New value: +[
+ "create",
+ "update"
+]Input schema / properties / address / descriptionPrevious value: -"Optional address: line_1, city, state, postcode, country (2-letter code)."New value: +"Address: line_1, city, state, postcode, country (2-letter code). For \"create\" and \"update\". On \"update\", provided fields are merged into the existing address (or a new address is created if none exists); omit the whole object to leave the address untouched — null is also treated as untouched, not cleared."Input schema / properties / balance / descriptionPrevious value: -"Optional starting client balance."New value: +"Optional starting client balance. \"create\" only."Input schema / properties / client_id / descriptionPrevious value: -"User id. Required when updating an existing record."New value: +"Client id. Required for \"update\"."Input schema / properties / company / descriptionPrevious value: -"Client company name. Max 255 characters."New value: +"Client company name. Max 255 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / company / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / created_at / descriptionPrevious value: -"Optional creation date/time for \"create\"."New value: +"Optional creation date/time. \"create\" only."Input schema / properties / email / descriptionPrevious value: -"Client email address. Required for \"create\"."New value: +"Client email address. Required for \"create\". Optional for \"update\" — cannot be cleared to null."Input schema / properties / name_f / descriptionPrevious value: -"Client first name. Max 64 characters."New value: +"Client first name. Max 64 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / name_f / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / name_l / descriptionPrevious value: -"Client last name. Max 64 characters."New value: +"Client last name. Max 64 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / name_l / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / note / descriptionPrevious value: -"Optional client note. Max 65535 characters."New value: +"Client note. Max 65535 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / note / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / optin / descriptionPrevious value: -"Optional marketing opt-in flag."New value: +"Marketing opt-in flag. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / optin / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Input schema / properties / phone / descriptionPrevious value: -"Client phone number. Max 64 characters."New value: +"Client phone number. Max 64 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / phone / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / referrer_user_id / descriptionPrevious value: -"Optional referring client/user ID."New value: +"Referring client ID. Must be a different client. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / referrer_user_id / typePrevious value: -"integer"New value: +[
+ "integer",
+ "null"
+]Input schema / properties / status_id / descriptionPrevious value: -"Optional client status ID. Omit to use the model default."New value: +"Client status ID. For \"create\" and \"update\"; omit to use the model default on \"create\" or leave untouched on \"update\". Cannot be null or empty."Input schema / properties / stripe_id / descriptionPrevious value: -"Optional Stripe customer ID. Must be unique."New value: +"Stripe customer ID. Must be unique. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / stripe_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / tax_id / descriptionPrevious value: -"Client tax ID. Max 255 characters."New value: +"Client tax ID. Max 255 characters. For \"create\" and \"update\"; omit to leave untouched on \"update\", null to clear."Input schema / properties / tax_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Input schema / properties / welcome_email / descriptionPrevious value: -"Whether to send the welcome email. Defaults to true."New value: +"Whether to send the welcome email. Defaults to true. \"create\" only."company-readcompany-writeorder-message-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."ticket-message-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."order-message-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."ticket-message-read2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."Input schema / properties / sort / descriptionPrevious value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."automation-readautomation-writeclient-custom-field-readclient-custom-field-writeclient-readclient-writecoupon-readcoupon-writeform-folder-readform-folder-writeform-readform-writeget-wayfront-docinvoice-toollog-toolorder-message-readorder-message-writeorder-readorder-task-readorder-task-writeorder-writepipeline-item-readpipeline-item-writepipeline-readpipeline-writesearch-wayfront-docsservice-readservice-writesettings-readsettings-writeslack-readslack-writesubscription-tooltag-readtag-writeteam-management-toolteam-tooltemplate-readtemplate-writeticket-message-readticket-message-writeticket-readticket-writeuser-activity-readuser-activity-writewebhook-readwebhook-writeworkspace-info
Add one secure layer between your agents and this server.