Skip to main content
Glama

autotask_update_ticket_charge

Update specific fields of a ticket charge without affecting others. Modify charge details like name, quantity, or billable status.

Instructions

Update an existing ticket charge. Only fields provided will be changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chargeIdYesThe charge ID to update
nameNoUpdated charge name
descriptionNoUpdated description
unitQuantityNoUpdated quantity
unitPriceNoUpdated unit price
unitCostNoUpdated unit cost
billableToAccountNoUpdated billable status
statusNoUpdated status

Implementation Reference

  • The handler function for autotask_update_ticket_charge in the dispatch table. Extracts chargeId from args, spreads remaining fields as updates, and delegates to autotaskService.updateTicketCharge().
    ['autotask_update_ticket_charge', async (a) => {
      const { chargeId, ...updates } = a;
      await s.updateTicketCharge(chargeId, updates);
      return { result: chargeId, message: `Successfully updated ticket charge ${chargeId}` };
    }],
  • Schema definition for autotask_update_ticket_charge. Input accepts chargeId (required), name, description, unitQuantity, unitPrice, unitCost, billableToAccount, and status.
      name: 'autotask_update_ticket_charge',
      description: 'Update an existing ticket charge. Only fields provided will be changed.',
      inputSchema: {
        type: 'object',
        properties: {
          chargeId: {
            type: 'number',
            description: 'The charge ID to update'
          },
          name: {
            type: 'string',
            description: 'Updated charge name'
          },
          description: {
            type: 'string',
            description: 'Updated description'
          },
          unitQuantity: {
            type: 'number',
            description: 'Updated quantity'
          },
          unitPrice: {
            type: 'number',
            description: 'Updated unit price'
          },
          unitCost: {
            type: 'number',
            description: 'Updated unit cost'
          },
          billableToAccount: {
            type: 'boolean',
            description: 'Updated billable status'
          },
          status: {
            type: 'number',
            description: 'Updated status'
          }
        },
        required: ['chargeId']
      }
    },
  • Tool registered in the 'tickets' category within TOOL_CATEGORIES, listing autotask_update_ticket_charge among the ticket-related tools.
      tools: ['autotask_search_tickets', 'autotask_get_ticket_details', 'autotask_create_ticket', 'autotask_update_ticket', 'autotask_get_ticket_note', 'autotask_search_ticket_notes', 'autotask_create_ticket_note', 'autotask_get_ticket_attachment', 'autotask_search_ticket_attachments', 'autotask_create_ticket_attachment', 'autotask_get_ticket_charge', 'autotask_search_ticket_charges', 'autotask_create_ticket_charge', 'autotask_update_ticket_charge', 'autotask_delete_ticket_charge', 'autotask_get_ticket_history', 'autotask_search_ticket_history']
    },
  • Service-layer implementation of updateTicketCharge. Calls http.update on the 'TicketCharges' entity with the charge ID and partial update data.
    async updateTicketCharge(id: number, updates: Partial<AutotaskTicketCharge>): Promise<void> {
      const http = await this.ensureClient();
      try {
        this.logger.debug(`Updating ticket charge ${id}:`, updates);
        await http.update('TicketCharges', id, updates as Record<string, any>);
        this.logger.info(`Ticket charge ${id} updated successfully`);
      } catch (error) {
        this.logger.error(`Failed to update ticket charge ${id}:`, error);
        throw error;
      }
    }
Behavior2/5

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

No annotations exist, so the description must carry behavioral disclosure. It states 'Only fields provided will be changed', which indicates partial update behavior. However, it does not mention permissions, idempotency, error handling, or side effects.

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

Conciseness2/5

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

The description is extremely short (two sentences) but lacks necessary detail for a tool with 8 optional parameters. It sacrifices completeness for brevity.

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

Completeness1/5

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

With no annotations, no output schema, and minimal description, the tool is incomplete for its complexity (8 parameters, update operation). It fails to provide sufficient context for correct 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% with descriptions for each parameter, so the schema already communicates param semantics. Description adds a generic behavioral note but no parameter-specific 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?

The description uses the verb 'Update' and resource 'ticket charge', clearly indicating an update operation. It is distinct from sibling tools like create and delete, but does not specify scope or limitations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus create/delete/search alternatives. Lacks context on prerequisites or conditions for appropriate use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wyre-technology/autotask-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server