Skip to main content
Glama

Record a bill on this order

p2p_record_vendor_bill

Record a vendor's bill against an order, line by line as printed. It is matched against what was ordered and received; a person approves paying it only when it matches. You were handed the vendor's invoice for goods on an order. Record it line by line as printed: the item, the quantity and the price for one, plus the vendor's invoice number and the dates. Never correct a line to make it match; the bill is what the vendor says, and the match exists to show where it differs. The result says whether it matches the order and, when it does not, by how much. Recording is never refused for a mismatch; approving it is. Tell the person what the match says; when it does not match, the answer is a corrected bill from the vendor (record it, and the person rejects the old one) or a person loosening the tolerance with a reason. Effects: bill recorded in Bills, waiting for approval; its lines kept for the 3-way match.

Input Schema

NameRequiredDescriptionDefault
linesYesWhat the bill charges, line by line.
po_idYesThe order the bill is for. An existing p2p_po id.
numberNoThe vendor's own invoice number, as printed.
reasonNoWhere it came from: "emailed by Acme on the 3rd".
categoryNoFor service lines only (freight, installation): what it is for, in the person's words.
due_dateNoWhen it is due, as printed. ISO date, YYYY-MM-DD.
bill_dateYesThe date on the bill. ISO date, YYYY-MM-DD.
file_hashNoA hash of that file, if you have one.
file_nameNoThe file you were handed, for the record.
terms_daysNoOr the days the bill gives (30 for net 30), when it prints no due date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description adds significant operational context beyond the basic hints in annotations, detailing that the bill is placed in a 'waiting for approval' state and that lines are 'kept for the 3-way match.' This gives the agent a full understanding of the resulting object's state.

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 detailed, which is necessary given the complexity of the 3-way matching workflow. While long, every part of the text conveys a vital operational constraint or outcome, preventing unnecessary fluff.

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 complex mutation tool without an explicit output schema, the description is exceptionally complete. It defines the system's logic regarding recording vs. approving, mismatch handling, and state persistence (waiting for approval).

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

Parameters4/5

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

Although the schema provides excellent coverage (100%), the description clarifies the operational semantics of the input, such as specifying the necessity of recording the 'vendor's own invoice number' and the critical instruction not to 'correct a line to make it match.'

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 purpose is stated very clearly: 'Record a vendor's bill against an order, line by line as printed.' This is precise and avoids ambiguity regarding what is being recorded.

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?

The description provides extensive guidance on workflow: recording as printed, the matching process against orders/receipt, and the difference between recording (never refused) and approving (required for payment).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.