Switchbooks

Search Journal Entries

manage_journal_entries

Read-onlyIdempotent

Find journal entries in the active company and inspect their accounting lines. Filter by entry reference, name, account, or a date range using YYYY-MM-DD dates. Use offset to continue a paginated list. Journal entries are separate from bank and credit card transactions. Set action to one of: list.

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": "manage_journal_entries"
  }
}

Input Schema

Name	Required	Description
`ref`	No
`date`	No
`memo`	No
`name`	No
`lines`	No
`names`	No
`payee`	No
`action`	No
`dryRun`	No
`offset`	No
`account`	No
`company`	No	Company for this call only: its ID, exact name, or a unique part of the name. Leave out to use the active company.
`confirm`	No
`endDate`	No
`entries`	No
`newName`	No
`maxAmount`	No
`minAmount`	No
`startDate`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- addedInput schema / properties / entries / items / properties / lines / items / properties / class
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / lines / items / properties / class
```
Added value: +{
+  "type": "string"
+}
```
First observedNov 2, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds useful behavioral context: active-company scope, offset-based pagination, and YYYY-MM-DD date formatting. It does not explain the return shape, pagination limits, or how write-like schema fields such as dryRun and confirm relate to a list-only action.

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-loads the core action before adding filtering details, pagination guidance, and scope separation. Most sentences earn their place. The final instruction to set action to the single enum value list is slightly redundant, but not enough to undermine clarity.

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?

This is a complex tool by schema size: 19 parameters, low schema description coverage, and no output schema. The description explains the core search behavior but leaves most parameters and the return structure unclear, which is a significant gap for correct invocation. More parameter documentation or a clearer statement about unsupported mutation fields is needed.

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 5% across 19 parameters, so the description must carry most of the parameter meaning. It covers ref, name, account, date range, offset, and action, but leaves many parameters unexplained, including memo, names, payee, minAmount, maxAmount, lines, entries, dryRun, confirm, and company override behavior. It also does not clarify which schema fields implement the stated date range.

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 a specific verb-resource pairing: find and inspect journal entries, including their accounting lines. It also distinguishes journal entries from bank and credit card transactions, which helps separate this from transaction-oriented siblings. The only gap is that the tool name says manage, while the description only supports a read/list action.

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?

Usage is implied by the search framing and the statement that journal entries are separate from bank and credit card transactions. However, it does not explicitly say when to use this versus named sibling tools such as manage_transactions or manage_reconciliations. The action constraint is stated, but alternatives and exclusions are only indirectly suggested.

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

All Switchbooks tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.