Skip to main content
Glama
advenimus

SyncroMSP MCP Server

by advenimus

scheduling_add_line_item

Add a line item to a recurring invoice schedule by setting line type, product, quantity, and pricing to bill assets, contacts, vendors, or subscriptions.

Instructions

Add a line item to a recurring invoice schedule. Needs name or product_id. Pricing is in cents (retail_cents, cost_cents) or dollars (price_retail, price_cost). recurring_type_id picks the line type, e.g. 4 bills a customer's assets by type and 9 bills the assets in a policy folder; the type-specific fields only apply to their type.

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
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. Changed31 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"
      +}
    • changedInput schema / properties / cost_cents / description
      Previous value: -"Cost in cents"New value: +"Your cost, in cents"
    • changedInput schema / properties / description / description
      Previous value: -"Description"New 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"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"Item name"New value: +"Line name on the invoice. A new line needs name or product_id."
    • changedInput schema / properties / one_time_charge / description
      Previous value: -"One-time charge (not recurring)"New 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"
      +}
    • changedInput schema / properties / position / description
      Previous value: -"Sort position"New 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"
      +}
    • changedInput schema / properties / product_id / description
      Previous value: -"Product ID"New value: +"Product to bill. name, description, and product_category default from it."
    • changedInput schema / properties / quantity / description
      Previous value: -"Quantity"New value: +"Quantity. Ignored for line types that count their own units (asset, contact, remote access, policy folder, vendor, Kabuto)."
    • changedInput schema / properties / recurring_type_id / description
      Previous value: -"Recurring type (1-6)"New 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
      +]
    • changedInput schema / properties / retail_cents / description
      Previous value: -"Retail price in cents"New 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"
      +}
    • changedInput schema / properties / user_id / description
      Previous value: -"User ID"New value: +"Employee credited with the line (default: API token owner)"
    • 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

A4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses important behavior: pricing units, that name or product_id is required, and that type-specific fields only apply to their recurring_type_id; however, it does not describe permissions, mutation side effects, or error behavior for mismatched fields.

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

Conciseness5/5

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

Four sentences, front-loaded with the purpose, then prerequisites, pricing conventions, and line-type semantics. Every sentence adds usable information and there is no filler.

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

Completeness4/5

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

For a 32-parameter mutation with no annotations and no output schema, the description covers purpose, prerequisites, pricing units, and type-specific field applicability. It omits permission requirements and side-effect details, but given full schema coverage it remains sufficient for selection and invocation.

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 coverage is 100%, so the schema already defines every parameter including alternatives and type-specific fields. The description restates key points (pricing in cents/dollars, needs name or product_id, recurring_type_id examples) but adds little beyond the schema's own descriptions.

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

Purpose5/5

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

States a specific verb and resource: add a line item to a recurring invoice schedule, which distinguishes it from sibling line-item tools for invoices, tickets, and estimates. An agent can identify the exact operation without opening the schema.

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

Usage Guidelines4/5

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

Provides clear context and prerequisites ('Needs name or product_id'), but does not explicitly name alternatives like scheduling_update_line_item or scheduling_remove_line_item. The context is clear enough to use it correctly, though 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.

Deploy Server

Other Tools