papers

propose_adjustment

Create a proposed adjusting entry, validate that debit and credit lines sum to zero, and commit changes only when mode is set to commit.

Instructions

Plan an adjusting entry. Defaults to validate: nothing is written unless mode is commit.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "engagement_id": "<engagement_id>",
      "description": "<description>",
      "lines": "<lines>"
    },
    "name": "propose_adjustment"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No		validate
`lines`	Yes	Lines must sum to zero
`rationale`	No	Why this entry exists, for the reviewer
`description`	Yes
`engagement_id`	Yes
`idempotency_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

A3.5/5.0

Behavior4/5

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

The description explicitly discloses the critical side-effect behavior: 'nothing is written unless mode is commit.' Since no annotations are provided, this is essential and well-handled. It does not disclose other behavioral aspects like validation errors or idempotency behavior, but the core write-safety concern is addressed.

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?

The description is one concise sentence, front-loading the tool's purpose and following with the key safety behavior. Every word earns its place; there is no redundancy or filler.

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?

For a tool with 6 parameters, no annotations, and no output schema, the description is too sparse to be complete. It covers the central write-safety behavior but omits context around required inputs, validation semantics, idempotency, and what a successful plan or commit returns.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description adds no parameter-level meaning beyond the mode default already present in the schema. The 'nothing is written unless mode is commit' line clarifies mode's behavioral effect, but engagement_id, description, rationale, and idempotency_key remain semantically undocumented.

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?

The description states a specific verb ('Plan') and resource ('an adjusting entry'), and the qualifier about validate mode makes clear this is a planning/write tool rather than a read tool. This differentiates it from the sibling tools, which are all read-oriented (get, list).

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?

The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like an existing engagement or trial balance. The only contextual hint is the planning-vs-commit distinction, which is more behavioral than usage guidance.

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

Deploy Server