Red by Big Red Cloud

Create Sales Invoice

brc_create_sales_invoice

Destructive

Creates a sales invoice with a caller-supplied reference and reconciled product, VAT and Sales-analysis lines. Missing customer contact values remain absent. Requires a valid routeToken issued for the matching action workflow. The token remains valid through lookup, preview and the permitted transaction. Placeholder tokens are invalid. A routeToken does not bypass preview or explicit-confirmation requirements. A call without confirmWrite: true returns confirmation_required and a payload preview. confirmWrite: true applies the previewed change after explicit confirmation. Passing preflight is not confirmation. Requires confirmCounterpartyExplicit: true; confirmation is scoped to the counterparty selected for the current preview.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional. BRC "Note" field on the sales document (JSON field `note`). Leave blank to default it to the customer name (BRC customer "Name" / JSON `name`). Do not use the product name as the note. Only set this when the user explicitly provides a note.
`acCode`	Yes
`procDate`	Yes
`quantity`	Yes
`entryDate`	Yes
`netAmount`	Yes
`productId`	Yes	productCode is the BRC product "Code" (JSON `productCode`); productId is the BRC product "Id" (JSON `productId`) from brc_list_products. The product name is not a payload field — do not place it in the BRC "Note" field (JSON `note`).
`reference`	No	Optional. BRC "Reference" field (JSON field `reference`). BRC "Our Ref" (JSON `ourReference`) and BRC "Your Ref" (JSON `yourReference`) default to this value when not supplied separately.
`saleRepId`	Yes	Sales rep id from brc_list_sales_reps.
`unitPrice`	Yes
`vatRateId`	Yes
`customerId`	Yes
`deliveryTo`	No	Optional. BRC "Delivery To" address (JSON field `deliveryTo`). Leave blank unless the user explicitly provides a delivery address. Do not invent or default a delivery address (for example "MCP Test").
`priceBasis`	No	Required when Gross Price Entry is enabled. Use `gross` when unit prices are VAT-inclusive/gross. Use `net` when unit prices are VAT-exclusive/net.
`routeToken`	Yes	Opaque routeToken from brc_route_request for this action workflow. Required for transactional tools. Routing permission only — does not replace preview-before-posting or confirmWrite.
`accountCode`	Yes
`companyName`	Yes	Company context name, for example YOUR-COMPANY-NAME.
`description`	Yes	Product line description shown on the document line (BRC product line description / JSON `tranNotes`, also used on the line's analysis entry description). This is the line narrative, not the BRC "Note" field.
`productCode`	Yes	productCode is the BRC product "Code" (JSON `productCode`); productId is the BRC product "Id" (JSON `productId`) from brc_list_products. The product name is not a payload field — do not place it in the BRC "Note" field (JSON `note`).
`saleRepCode`	Yes	Sales rep code from brc_list_sales_reps.
`confirmWrite`	No	Must be true only after a plain-English preview before posting has been shown in the current conversation and the user explicitly confirmed posting (for example yes, create it / post it now / confirm). Never set true on the first call or because the user initially asked to create something. Nothing is written to Big Red Cloud until you confirm.
`customerName`	No	Optional. The selected customer's name (BRC customer "Name" / JSON `name`). Used as the default sales document note (BRC "Note" / JSON `note`) when no explicit note is given.
`connectionRef`	No	Opaque Red connection reference returned by brc_confirm_company_connection. Pass this exact value on every later tool call when the MCP client rotates session ids (for example Vibe/Mistral). Keep reusing the same connectionRef after successful tool calls — do not start a new connection because a lookup returned empty or partial data. It is not an API key and does not contain credentials.
`vatPercentage`	Yes
`bookTranTypeId`	Yes
`analysisCategoryId`	Yes
`confirmCrAnalysisCategory`	No	Set true only after the user confirms a CR sales analysis account code is intentional for this product line.
`confirmCounterpartyExplicit`	No	Must be true only after the user explicitly named or confirmed the customer, supplier, or other counterparty in the current conversation. Never set true because a customer or supplier appeared in an earlier preview, was inferred from context, or was filled in without the user's explicit choice in this conversation.

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description goes far beyond them by disclosing token validity windows, placeholder token invalidity, the fact that a routeToken does not bypass preview or confirmation, that a call without confirmWrite returns confirmation_required plus a payload preview, that passing preflight is not confirmation, and that counterparty confirmation is scoped to the current preview. No contradiction with the annotations exists.

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 dense (~130 words) and front-loaded with the core action before moving into the confirmation protocol. Every sentence carries operational weight; the mild redundancy between 'A routeToken does not bypass preview or explicit-confirmation requirements' and 'Passing preflight is not confirmation' is acceptable given the financial impact of misconfirmation.

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 28-parameter, no-output-schema tool, the description covers the critical return behavior of the pre-confirmation call (confirmation_required plus payload preview) and the full token/preview/confirm lifecycle. It does not describe the final success response shape or the concrete preview payload contents, and several required accounting params remain unexplained; however, the workflow hazards most likely to cause agent errors (invalid tokens, premature confirmation, unconirmed counterparties) are thoroughly addressed.

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 description coverage is 57%, so the description must partially compensate. It adds meaning for reference ('caller-supplied reference'), customer contact behavior ('Missing customer contact values remain absent'), and the token/confirmation flags, but it says nothing about the undocumented accounting fields (acCode, entryDate, procDate, bookTranTypeId, analysisCategoryId, accountCode, customerId, vatPercentage), which remain semantically empty in both the schema and the description.

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: 'Creates a sales invoice with a caller-supplied reference and reconciled product, VAT and Sales-analysis lines.' This precisely distinguishes it from sibling create tools like brc_create_sales_entry and brc_create_sales_credit_note, and from brc_create_sales_invoice_gen_ref which only generates a reference rather than creating the invoice.

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 establishes a clear workflow context: a routeToken from brc_route_request that remains valid through lookup, preview and the permitted transaction, plus an explicit two-phase confirmation protocol (confirmWrite: true only after preview and explicit confirmation; confirmCounterpartyExplicit required). However, it never names sibling alternatives such as brc_batch_sales_invoices or brc_generate_sales_invoice_from_quote, so tool-selection among create-variants is left to inference rather than explicit routing.

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

All Red by Big Red Cloud tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have a clear single resource-and-action focus, and the systematic naming helps an agent separate create/get/update/delete/list operations. The main confusion risks are the help/search cluster (red_help, find_help_resources, get_help_resource_details) and the payment/cash-payment/batch-payment variants, which require careful reading of the descriptions to avoid misselection.

Naming Consistency4/5

The brc_ prefix with snake_case verb_noun naming is used consistently across the vast majority of tools, e.g. brc_list_customers, brc_create_sales_invoice, brc_delete_purchase. A few noun-style names like brc_company_readiness_check, brc_grouped_nominal_accounts_report, and brc_red_help break the pattern, but these are minor deviations.

Tool Count1/5

159 tools is an extreme count for an MCP server, well beyond the 50+ threshold described as an extreme mismatch. While the accounting domain is broad, the surface is inflated by batch variants, generated-reference variants, and without-dormant list variants that could be consolidated.

Completeness4/5

Core accounting entities have strong lifecycle coverage: customers, suppliers, products, sales reps, bank accounts, quotes, sales invoices/entries/credit notes, purchases, payments, cash receipts, accruals, prepayments, and nominal journal batches all support relevant CRUD and batch operations. Minor gaps include the quote update being limited to the reference only, no update/create tools for VAT categories or company settings, and email sending being limited to quotes, invoices, and statements.

Create Sales Invoice

Input Schema

TDQS

Glama MCP Gateway

TDQS

Resources