Conecto

Record a prepayment to a supplier

purchasing_record_prepayment

Record money the business paid a supplier before their bill, like a deposit, as Xero's prepayments: it waits as a credit with the supplier (SC-0001 on) until purchasing_use_credit puts it on their bill or records it coming back. With tax_rate it carries the VAT on the supplier's advance invoice, reclaimable once paid; using it on the bill takes that VAT back off. With books kept it is posted at once: Prepayments to suppliers (1450, made when missing) and the tax to reclaim against the bank. Costs $0.01 per call; nothing if it fails.

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": {
      "supplier": "<supplier>",
      "amount": "<amount>"
    },
    "name": "purchasing_record_prepayment"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No	When it was paid. Default today.
`note`	No
`amount`	Yes	What was paid, tax included.
`method`	No		bank_transfer
`currency`	No	ISO 4217, e.g. "EUR". Default: the supplier's.
`supplier`	Yes	A supplier_id, or the supplier's name.
`tax_rate`	No	The VAT in it, in percent, e.g. 19. Default none.
`reference`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds real value beyond annotations: per-call cost ($0.01, free on failure), immediate posting to Prepayments to suppliers (1450) with the account auto-created if missing, and the VAT reclaim/offset cycle. The notable gap is idempotentHint=false — nothing warns that a retry creates a duplicate prepayment — and it doesn't say what the call returns.

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?

Three sentences, front-loaded with the core action and lifecycle, and the cost caveat is a tidy closer. Some phrasing is opaque shorthand ('SC-0001 on', '1450') that costs the reader without much payoff.

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 an 8-parameter mutation tool with no output schema, the description covers the economically important parts: what state the prepayment lands in, which ledger accounts are touched, how VAT is handled, and the cost model. Missing field-level notes on method/note/reference are minor given schema coverage.

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 63%, so several parameters (method, note, reference) are undocumented in both places. The description does add genuine semantics for tax_rate — that the VAT rides on the advance and is reclaimed, then reversed when the credit is applied — but date, currency and amount are left to 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?

Names a specific verb and resource ('Record money the business paid a supplier before their bill ... as Xero's prepayments') and distinguishes it from siblings by naming purchasing_use_credit as the consumer of the resulting credit. An agent can tell this apart from purchasing_create_bill or purchasing_pay_bill without opening any 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?

Explains the position in the workflow clearly: the credit sits with the supplier until purchasing_use_credit applies it to a bill or records a refund. It gives clear context for when this tool applies ('before their bill, like a deposit') but never states an explicit when-not case, e.g. that an existing bill should go through purchasing_create_bill instead.

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

All Conecto 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?