Skip to main content
Glama
advenimus

SyncroMSP MCP Server

by advenimus

scheduling_update_line_item

Update a schedule line item in SyncroMSP by modifying only the fields you specify.

Instructions

Update a line item on a schedule. Takes the same fields as scheduling_add_line_item; only the fields you send change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesSchedule ID
nameNoLine name on the invoice. A new line needs name or product_id.
taxableNoTaxable
user_idNoEmployee credited with the line (default: API token owner)
positionNoSort order on the invoice (default: bottom)
quantityNoQuantity. Ignored for line types that count their own units (asset, contact, remote access, policy folder, vendor, Kabuto).
cost_centsNoYour cost, in cents
price_costNoYour cost, in dollars (alternative to cost_cents)
product_idNoProduct to bill. name, description, and product_category default from it.
descriptionNoLonger text under the name
vendor_nameNoVendor lines (type 10): vendor to read usage from
line_item_idYesSchedule line item ID
price_retailNoPrice charged, in dollars (alternative to retail_cents)
retail_centsNoPrice charged, in cents
asset_type_idNoAsset lines (type 4): bill the customer's assets of this type
bill_all_unitsNoBill every unit, not just those over bill_units_threshold
m365_unit_typeNoMicrosoft 365 vendor lines: bill licensed ('all') or consumed seats
one_time_chargeNoBill once, then stop
policy_folder_idNoPolicy folder lines (type 9): bill the assets in this folder
product_categoryNoProduct category (overwritten by the product's category when product_id is set)
recurring_type_idNoLine type, which decides how quantity is counted: 1 recurring invoice, 2 data backup, 3 general subscription, 4 asset, 5 Kabuto, 6 contact, 7 Syncro Backup, 8 remote access, 9 policy folder, 10 third-party vendor, 11 Cloudberry
bill_nested_foldersNoPolicy folder lines (type 9): include sub-folders
include_zero_chargeNoKeep the line on the invoice even when it bills nothing
vendor_product_nameNoVendor lines (type 10): vendor product to bill
bill_units_thresholdNoUnits included before billing starts. Required when bill_all_units is false.
contact_field_type_idNoContact lines (type 6): bill contacts by this custom field
saved_asset_search_idNoAsset lines (type 4): bill assets matching this saved search instead of a type
syncro_backup_bill_allNoSyncro Backup lines: bill all usage, ignoring the included allowance
contact_field_answer_idNoContact lines (type 6): only contacts with this answer to that field
syncro_backup_credit_typeNoSyncro Backup storage lines: included storage is global or per asset
syncro_backup_billing_typeNoSyncro Backup lines (type 7): bill per license or per GB stored
syncro_backup_bill_after_storageNoSyncro Backup storage lines: GB included before billing starts
syncro_backup_bill_after_licensesNoSyncro Backup license lines: licenses included before billing starts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed32 schema fields changedv1.10.0
    • addedInput schema / properties / asset_type_id
      Added value: +{
      +  "description": "Asset lines (type 4): bill the customer's assets of this type",
      +  "type": "number"
      +}
    • addedInput schema / properties / bill_all_units
      Added value: +{
      +  "description": "Bill every unit, not just those over bill_units_threshold",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / bill_nested_folders
      Added value: +{
      +  "description": "Policy folder lines (type 9): include sub-folders",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / bill_units_threshold
      Added value: +{
      +  "description": "Units included before billing starts. Required when bill_all_units is false.",
      +  "type": "number"
      +}
    • addedInput schema / properties / contact_field_answer_id
      Added value: +{
      +  "description": "Contact lines (type 6): only contacts with this answer to that field",
      +  "type": "number"
      +}
    • addedInput schema / properties / contact_field_type_id
      Added value: +{
      +  "description": "Contact lines (type 6): bill contacts by this custom field",
      +  "type": "number"
      +}
    • addedInput schema / properties / cost_cents / description
      Added value: +"Your cost, in cents"
    • addedInput schema / properties / description / description
      Added value: +"Longer text under the name"
    • addedInput schema / properties / include_zero_charge
      Added value: +{
      +  "description": "Keep the line on the invoice even when it bills nothing",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / m365_unit_type
      Added value: +{
      +  "description": "Microsoft 365 vendor lines: bill licensed ('all') or consumed seats",
      +  "enum": [
      +    "all",
      +    "consumed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / name / description
      Added value: +"Line name on the invoice. A new line needs name or product_id."
    • addedInput schema / properties / one_time_charge / description
      Added value: +"Bill once, then stop"
    • addedInput schema / properties / policy_folder_id
      Added value: +{
      +  "description": "Policy folder lines (type 9): bill the assets in this folder",
      +  "type": "number"
      +}
    • addedInput schema / properties / position / description
      Added value: +"Sort order on the invoice (default: bottom)"
    • addedInput schema / properties / price_cost
      Added value: +{
      +  "description": "Your cost, in dollars (alternative to cost_cents)",
      +  "type": "number"
      +}
    • addedInput schema / properties / price_retail
      Added value: +{
      +  "description": "Price charged, in dollars (alternative to retail_cents)",
      +  "type": "number"
      +}
    • addedInput schema / properties / product_category
      Added value: +{
      +  "description": "Product category (overwritten by the product's category when product_id is set)",
      +  "type": "string"
      +}
    • addedInput schema / properties / product_id / description
      Added value: +"Product to bill. name, description, and product_category default from it."
    • addedInput schema / properties / quantity / description
      Added value: +"Quantity. Ignored for line types that count their own units (asset, contact, remote access, policy folder, vendor, Kabuto)."
    • addedInput schema / properties / recurring_type_id / description
      Added value: +"Line type, which decides how quantity is counted: 1 recurring invoice, 2 data backup, 3 general subscription, 4 asset, 5 Kabuto, 6 contact, 7 Syncro Backup, 8 remote access, 9 policy folder, 10 third-party vendor, 11 Cloudberry"
    • addedInput schema / properties / recurring_type_id / enum
      Added value: +[
      +  1,
      +  2,
      +  3,
      +  4,
      +  5,
      +  6,
      +  7,
      +  8,
      +  9,
      +  10,
      +  11
      +]
    • addedInput schema / properties / retail_cents / description
      Added value: +"Price charged, in cents"
    • addedInput schema / properties / saved_asset_search_id
      Added value: +{
      +  "description": "Asset lines (type 4): bill assets matching this saved search instead of a type",
      +  "type": "number"
      +}
    • addedInput schema / properties / syncro_backup_bill_after_licenses
      Added value: +{
      +  "description": "Syncro Backup license lines: licenses included before billing starts",
      +  "type": "number"
      +}
    • addedInput schema / properties / syncro_backup_bill_after_storage
      Added value: +{
      +  "description": "Syncro Backup storage lines: GB included before billing starts",
      +  "type": "number"
      +}
    • addedInput schema / properties / syncro_backup_bill_all
      Added value: +{
      +  "description": "Syncro Backup lines: bill all usage, ignoring the included allowance",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / syncro_backup_billing_type
      Added value: +{
      +  "description": "Syncro Backup lines (type 7): bill per license or per GB stored",
      +  "enum": [
      +    "license_count",
      +    "cloud_storage_usage"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / syncro_backup_credit_type
      Added value: +{
      +  "description": "Syncro Backup storage lines: included storage is global or per asset",
      +  "enum": [
      +    "global_credit",
      +    "per_asset_credit"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / taxable / description
      Added value: +"Taxable"
    • addedInput schema / properties / user_id
      Added value: +{
      +  "description": "Employee credited with the line (default: API token owner)",
      +  "type": "number"
      +}
    • addedInput schema / properties / vendor_name
      Added value: +{
      +  "description": "Vendor lines (type 10): vendor to read usage from",
      +  "type": "string"
      +}
    • addedInput schema / properties / vendor_product_name
      Added value: +{
      +  "description": "Vendor lines (type 10): vendor product to bill",
      +  "type": "string"
      +}
  2. First observedv0.1.1

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the partial-update semantic (only sent fields change), but says nothing about required permissions, whether changes are reversible, the effect of clearing a field, or error behavior for a 33-parameter mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler; the purpose is front-loaded and the second sentence adds a genuinely useful semantic. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given full schema coverage and no output schema, the description need not restate fields or return values, and it covers purpose plus the partial-update rule. But for a 33-parameter, unannotated mutation it is thin on permissions, safety profile, and error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all 33 parameters and their enums. The description adds only the partial-update rule and the pointer to scheduling_add_line_item for field semantics, which is marginal additional value. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update a line item on a schedule'), which cleanly distinguishes it from scheduling_add_line_item and scheduling_remove_line_item. It does not explicitly name the alternatives, so a slightly lower mark than a definition that routes the agent directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The clause 'only the fields you send change' implies a partial-update workflow, which is useful context for choosing this over add/remove. However, there is no explicit when-to-use, when-not-to-use, or named alternative, so guidance is only implied.

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

Deploy Server

Other Tools