Skip to main content
Glama
ninetails-io

gnucash-mcp

by ninetails-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_taxtables

Read-only

List sales-tax tables from GnuCash books with rates and account routing. Fetch a single table by name, or page through all with offset and limit.

Instructions

List all sales-tax tables, or get one by name.

Leads with a Showing X-Y of Z taxtables line. Compact format (default): one line per taxtable with name, entry count, and per-entry rate→account routing. Page with offset; limit=0 returns the count only. Verbose: structured JSON with resolved account paths and refcount.

Args: name: Tax table name for a single-table detail lookup (entries, rates, account routing, refcount). All other parameters are ignored. verbose: If false (default), compact text output — optimized for reading and token efficiency. If true, structured JSON, for when you need machine-readable fields rather than a report. limit: Page size (default 50, max 250). 0 = count only. offset: 0-indexed first row to return (default 0).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
limitNo
offsetNo
verboseNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.4
    • addedInput schema / properties / name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Name"
+}
  2. First observedv1.4.2

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the output lead line, pagination behavior, limit=0 count-only behavior, compact vs verbose formats, and that supplying name causes all other parameters to be ignored. No contradiction with annotations.

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 tightly organized: a one-sentence purpose summary, behavioral output notes, and a compact Args list. Every sentence adds operational value with no filler.

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

Completeness5/5

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

For a read-only list/detail tool, the description covers output format, pagination, count-only behavior, verbose mode, and parameter interactions. Since an output schema exists, the absence of exhaustive return-field documentation is acceptable.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries full responsibility for parameter semantics. It explains all four parameters, including defaults, max page size, the special limit=0 meaning, and the interaction where name ignores other parameters.

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 opens with a specific verb and resource: 'List all sales-tax tables, or get one by name.' This clearly covers both modes of the tool and distinguishes it from create/update/delete taxtable siblings.

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

Usage Guidelines4/5

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

The description gives clear context for when to use each mode: compact text for reading/token efficiency, verbose JSON for machine-readable output, and the name parameter for single-table detail lookups. It does not explicitly name alternative tools or state when-not-to-use, but the usage context is clear.

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