Skip to main content
Glama
ninetails-io

gnucash-mcp

create_prices

Stop entering prices one by one; record many commodity or currency quotes in a single call, with existing entries updated instead of duplicated.

Instructions

Record MANY prices in one call (bulk quote entry).

INPUT — prices is a TSV block: a header row, then one row per price. Required columns ref, commodity, date, value; optional columns extend the header IN ORDER: ns, cur, source, type (stop anywhere; rows may end early; empty cells take defaults)::

ref<TAB>commodity<TAB>date<TAB>value<TAB>cur<TAB>source
1<TAB>VTSAX<TAB>2026-07-21<TAB>148.32<TAB><TAB>web:yahoo
2<TAB>EUR<TAB>2026-07-21<TAB>1.0845<TAB><TAB>web:ecb
  • ref: your correlation key, echoed in results.

  • ns: commodity namespace; empty auto-resolves when the symbol is unambiguous across namespaces.

  • cur: quote currency; empty = book default.

  • source: where the quote came from (provenance — default "user:price"); type: nav/last/bid/ask.

Per-row semantics are create_price's exactly: an existing price with the same commodity/currency/date/source is UPDATED in place (status: updated), never duplicated. One book open, one save, on_error="abort" (default) sinks the whole batch on any bad row; dry_run=true previews as would_create / would_update.

The companion work list: list_commodities(stale_days=30, held_only=true).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pricesYes
dry_runNo
on_errorNoabort

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Despite no annotations being provided, the description thoroughly discloses behavioral traits: update-in-place semantics (never duplicated), atomic batch behavior on error, dry_run preview states (would_create/would_update), provenance default, currency default to book default, and namespace auto-resolution. This fully carries the burden normally expected of 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?

Exceptionally well-structured: bold labels (INPUT, required/optional columns), a concrete TSV example, colon-delimited parameter explanations, semantic reference to create_price, and a companion work-list note. Every sentence adds value with zero waste.

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 tool with 3 params, 0% schema coverage, and an output schema, the description is complete: it documents input format precisely, error modes, update semantics, defaults, and edge cases (empty cells take defaults, rows may end early). The mention of the output schema behavior via status/would_create/would_update states ties the documented behavior to expected results.

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?

With 0% schema description coverage, the description fully compensates by documenting every parameter in detail: the prices TSV format with required/optional columns, ref as correlation key, ns auto-resolution, cur defaulting, source/type semantics, plus dry_run and on_error default values and behaviors. The TSV example makes the format unambiguous.

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 clearly states the tool records MANY prices in one call (bulk quote entry) with specific verb+resource+scope. It distinguishes from the sibling create_price by emphasizing it's the bulk version, and explicitly references per-row semantics being create_price's exactly.

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

Usage Guidelines5/5

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

Provides explicit when-to-use (bulk entry), detailed input format, error handling behavior (on_error='abort'), dry_run preview behavior, and even a companion work list suggestion (list_commodities with specific parameters). This is exceptionally actionable guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ninetails-io/gnucash-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server