OrgLines

Invoices: Mark paid

invoice_mark_paid

Destructive

Record that the client paid: without 'amount' the whole remaining balance («рахунок 12 оплачено»), with 'amount' a partial payment of exactly that sum; optional date (YYYY-MM-DD) and method. Recorded by mistake → invoice_undo_payment within 10 minutes. Runs propose→confirm. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": {
      "invoice": "<invoice>"
    },
    "name": "invoice_mark_paid"
  }
}

Input Schema

Name	Required	Description
`date`	No
`amount`	No
`method`	No
`invoice`	Yes	The invoice's number as the person said it (INV-12, 12) or its id.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already flag a destructive write, and the description adds important behavior beyond that: the propose-to-confirm flow, the returned status and action_id/plan_token, the 10-minute undo path, and the full-versus-partial payment semantics.

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 front-loaded and information-dense, starting with payment semantics before recovery and confirmation details. There is slight redundancy between 'Runs propose→confirm' and the uppercase confirmation explanation, but the workflow is still easy to scan.

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 destructive mutation with no output schema, the description covers the required workflow, full/partial payment behavior, optional parameters, confirmation handshake, returned confirmation fields, and undo path. No critical invocation detail appears to be missing.

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 only 25%, so the description must carry parameter meaning. It does so by explaining the critical 'amount' semantics, the date format YYYY-MM-DD, and the optional method parameter, while the invoice identifier is documented in 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: recording that an invoice was paid. It clearly distinguishes full-balance payment from partial payment using the presence or absence of 'amount', and names the mistake-recovery sibling invoice_undo_payment.

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?

It gives explicit usage conditions: omit 'amount' for the whole remaining balance, include 'amount' for a partial payment of exactly that sum. It also directs the agent to invoice_undo_payment for mistakes within 10 minutes and explains that the tool is proposed rather than directly performed.

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

All OrgLines 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.

Resources

Need Help?