lightbulb-mcp

Overview Schema Source Related Servers Discussions Admin

xero_trial_balance_report

Read-onlyIdempotent

Retrieve a trial balance report from Xero through a governed connector. Pull accurate financial balances for project analysis and decision-making.

Instructions

Xero connector operation trial_balance_report (platform tool xero.trial_balance_report).

Routes only through the exact project/account governed connector authority.

Args: arguments: JSON string of arguments for the connector operation. 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: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema

Name	Required	Default
`effect`	Yes
`arguments`	No	{}
`project_id`	No
`project_ref`	No
`approval_ref`	No
`idempotency_key`	No
`connector_account_ref`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.1Sep 7, 2026

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: +{
+  "const": "read",
+  "title": "Effect",
+  "type": "string"
+}

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"
+}

addedInput schema / required
```
Added value: +[
+  "effect"
+]
```

First observedv0.1.0Jun 25, 2026

TDQS

C2.7/5.0

Behavior3/5

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

The description does add governance and routing context beyond the annotations: exact connector authority, required `read` effect verified by Spring, and idempotency semantics. However, the `approval_ref` line mentions resuming a write in an explicitly read-only, effect=read tool, which is confusing and slightly undercuts the readOnlyHint.

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 description is compact and front-loaded with identity and routing, then lists the parameters in Arg list form. The opening line is somewhat redundant with the tool name but the description neither pads nor drifts into unrelated prose.

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

Completeness2/5

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

The description handles the governance wrapping but does not explain the actual domain behavior of a trial balance report or what should go inside the `arguments` JSON string. With output schema present return-value structure may be partially covered, but an agent still does not know how to target the report or what period/account scope to specify.

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?

Schema description coverage is 0%, so the description is the only documentation for all seven parameters. It gives each parameter a useful business meaning, including authenticated `project_id`, project-bound `connector_account_ref`, stable `idempotency_key`, and effect verification. The `arguments` field remains opaque as a JSON string, but the common governance parameters are at least semantically explained.

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

Purpose2/5

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

The description restates the tool name ('Xero connector operation `trial_balance_report`') without saying what a trial balance report actually is or what the tool produces. There is no domain-level purpose sentence, and it does not differentiate from similar report tools such as `xero_balance_sheet_report`, `xero_profit_loss_report`, or `quickbooks_trial_balance_report`.

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 given about when to prefer this tool over sibling reporting or connector tools. 'Routes only through the exact project/account governed connector authority' is a routing constraint, not usage guidance, and there are no scenarios, prerequisites, or when-not-to-use notes.

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

Deploy Server