Skip to main content
Glama

xero_update_manual_journal

DestructiveIdempotent

Update a manual journal in Xero by submitting revised journal entries via the connector.

Instructions

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

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: Claimed read or write effect; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
effectNo
argumentsNo{}
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
connector_account_refNo

Output Schema

TableJSON 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

D1.1/5.0
Behavior1/5

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

The description discloses no behavioral traits. While annotations indicate destructiveHint=true and idempotentHint=true, the description adds nothing beyond those annotations. It does not mention that the operation modifies an existing manual journal, any side effects, permission requirements, or the purpose of parameters like 'effect' or 'approval_ref'.

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 short and not verbose, but it is not front-loaded with useful information. The first sentence is a tautology repeating the tool name, and the second sentence is a generic routing phrase. While concise in length, it lacks meaningful content and does not structure information in a way that aids understanding.

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?

Given that this is a mutation operation on a financial record (manual journal) within a complex connector ecosystem, the description provides virtually no context. It does not explain the operation's purpose, the structure of the required arguments, the meaning of the governance parameters, or any integration details. The presence of an output schema is noted but not described, leaving the tool's behavior entirely opaque.

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

Parameters1/5

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

The parameter descriptions are generic boilerplate: 'arguments' is described as 'JSON string of arguments for the connector operation', which does not explain what those arguments should be. Other parameters like 'project_id' and 'connector_account_ref' have equally generic descriptions that provide no domain-specific meaning. With 0% schema description coverage, the description fails to compensate or clarify any parameter semantics.

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

Purpose1/5

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

The description merely repeats the tool name ('update_manual_journal') and adds a generic routing statement ('Routes only through the exact project/account governed connector authority') that applies to all connector tools. It does not explain what updating a manual journal entails, what a manual journal is, or what specific action is performed, providing no distinct purpose beyond the name itself.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus any sibling tool. The description does not explain how to construct the 'arguments' JSON string, what fields are required, or any context about manual journals. No usage scenarios, preconditions, or alternative considerations are mentioned.

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