Skip to main content
Glama
Sign In
lightbulb-mcp

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

xero_create_invoice

DestructiveIdempotent

Create a draft Xero invoice using a contact ID and line items with account codes; optionally set due date and reference.

Instructions

Create a draft invoice in Xero. Use the contact ID from xero.list_contacts; line items reference Xero account codes.

Args: contact_id (required): Xero contact ID. line_items (required): JSON-string list of line items: [{description, quantity, unit_amount, account_code}]. due_date: Due date (YYYY-MM-DD). reference: Customer-facing invoice reference. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Claimed read or write effect; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "xero_create_invoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
effectNo
due_dateNo
referenceNo
contact_idNo
line_itemsNo
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
connector_account_refNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}
    • addedInput schema / properties / effect
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Effect"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}
    • addedInput schema / properties / project_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already signal non-read-only, idempotent, and destructive hints, so the bar for additional behavioral disclosure is lower. The description adds valuable context: it creates a draft (non-final), mentions that Spring verifies the claimed effect, and explains approval_ref as resuming a write. It does not explain why destructiveHint is true, but 'draft invoice' softens that and the description 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.

Conciseness4/5

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

The one-sentence purpose is front-loaded, and the Args block is structured so each parameter gets its own line. It is longer than a minimal description, but with 10 parameters the detail is justified and mostly free of fluff.

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?

Given the 10-parameter surface, existing output schema, and annotations, the description is largely complete: it names the source for contact data, defines the line-item format, and explains the platform-correlation parameters. It could be improved by mentioning where to get Xero account codes and by explicitly excluding alternatives such as xero_intake_invoice, but nothing essential for making the call is missing.

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

Parameters4/5

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

With 0% schema description coverage, the description carries the full param-documentation burden, and it documents all 10 parameters with concrete meanings. It clarifies the line_items JSON-string shape and the meaning of project_id, project_ref, connector_account_ref, idempotency_key, effect, and approval_ref. Minor deduction because it marks contact_id/line_items as required while the schema lists them as optional/nullable, leaving a small consistency gap.

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?

Description opens with a specific verb and resource: 'Create a draft invoice in Xero.' It also distinguishes this from sibling tools by specifying the draft state and by pointing to xero.list_contacts for the contact ID. An agent can tell this apart from xero_intake_invoice or xero_create_bill without opening schemas.

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 description gives a useful prerequisite ('Use the contact ID from xero.list_contacts') and implies the tool is for draft invoice creation, but it never names alternatives or states when not to use it. The guidance is therefore mostly inferential rather than explicit routing among the many Xero and invoice-related siblings.

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