Skip to main content
Glama
Sign In

Ekwo OS — open source accounting: ledger, invoices and VAT on your own Supabase or Postgres

by ai.ekwo
OverviewDiscussionsAdmin

Leave a ledger line without a contact

leave_line_unnamed

Records that an open line on a receivable or payable account names nobody on purpose — a cash difference, a one-off refund — with the user's reason: suggest_line_contacts no longer proposes it. The line does not move and stays an open item. Refused by name: unknown_line, not_allowed, reason_required, reason_too_long, line_not_posted, line_has_contact, line_not_third_party, line_left_unnamed. Ask the user before calling it.

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": {
      "line_id": "<line_id>",
      "reason": "<reason>"
    },
    "name": "leave_line_unnamed"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonYesWhy the line names nobody, in the user's words.
line_idYesThe open line on a receivable or payable account that names nobody, as suggest_line_contacts returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / line_id / description
      Added value: +"The open line on a receivable or payable account that names nobody, as suggest_line_contacts returns it."
    • addedInput schema / properties / line_id / format
      Added value: +"uuid"
    • addedInput schema / properties / line_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • addedInput schema / properties / reason / description
      Added value: +"Why the line names nobody, in the user's words."
    • addedInput schema / properties / reason / maxLength
      Added value: +500
    • addedInput schema / properties / reason / minLength
      Added value: +1
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: the line does not move and remains an open item, suggest_line_contacts stops proposing it, and specific refusal codes are listed. This is unusually rich behavioral context for a mutation tool.

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 front-loaded with the operation's purpose before the effect and refusal list. Every sentence adds useful information: operational meaning, line behavior, refusal names, and the instruction to ask the user.

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

Completeness4/5

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

For a two-parameter mutation with full schema coverage and no output schema, the description covers purpose, refusal cases, user confirmation, and effect on the line. It does not mention reversibility via undo_leave_line_unnamed or what a successful response contains, leaving a small completeness gap.

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

Parameters3/5

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

Schema coverage is 100%, and both parameters already have clear schema descriptions. The description reinforces that reason is in the user's words and that line_id comes from suggest_line_contacts, but it adds little syntax or validation detail beyond the schema.

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 and resource: records that an open receivable/payable line intentionally names no contact. It also gives concrete examples (cash difference, one-off refund) and distinguishes the effect from suggest_line_contacts, so the agent can understand the operation without opening the schema.

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?

It gives clear situational context (cash difference, one-off refund) and explicitly instructs the agent to ask the user before calling it. It stops short of naming alternatives such as set_line_contact or undo_leave_line_unnamed and does not state when not to use this tool.

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

All Ekwo OS — open source accounting: ledger, invoices and VAT on your own Supabase or Postgres toolsInspect
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.

Resources