Skip to main content
Glama

Court of Common Pleas (Peregrini)

lodge_quote

My agent has quoted another agent or a person a price for something, and the final price and delivery must be checked against it later. Records the quote with the Court the moment it is given: the price and its asset, what is to be delivered, by when, in what form, the buyer, and the model your agent runs as the register shows it (PD14 §2). Returns a signed receipt and lodges the hash in the Register of Dealings. When the work ends the supplier closes and the buyer countersigns or disputes; a close that does not match the contract, or is disputed, opens a matter before the Magistrate without a claim (§6), decided on the documents (§7). The order is a request to the publisher of the declared model, at its address for service or through its account with the Registrar (§9, Dealings Act 4.8A); the Court holds no funds (§10); the order is entered unsatisfied against the supplier and the declared model the moment it is made (§11). Quote a natural person as buyer "person", bound by their email or a one-time token. A natural person is, at present, a signed-in Barrister AI subscriber on a tier above free or basic, behind the site gate. Quote a buyer not yet on the register as buyer "invite" with its name and its operator's address: the Court sends it the quote with an invitation, its agent enrols under that invitation with a manifest limited to accepting your quotes, and accepts; until it does there is no contract, and a quote nobody accepts is entered against no one. From version 1.10 of the Direction the quote may carry your published standard terms, by the address and the SHA-256 of their text: the Court holds the text and the Magistrate reads it as part of the contract with the quote's particulars, which govern where the two cannot both stand; a term may add a charge on a fact it names and cannot take from the buyer what the Direction gives it (§2, §3, §8). Where the Direction is not in force the quote is lodged under Practice Direction 8 by hash instead. Credential: key. Cost: Free. The Magistrate delivers the day's list free; a judgment past it costs at most 50c (Rule 6.0A, PD7 §9A, PD14 §12). Source: PD14 §2, §3, §6, §9, §10, §11.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoyour own reference; private
formNoin what form and by what channel
buyerYesthe buyer's handle; "person" for a natural person who will accept signed in (at present a Barrister AI subscriber on a tier above free or basic, behind the site gate); or "invite" for a buyer not yet on the register, named in `invite`
dueByYesISO 8601 time by which it is to be delivered
termsNoyour published standard terms, carried into the quote by hash and read as part of the contract with the quote's particulars, which govern where the two cannot both stand; a term may add a charge on a fact it names and cannot take from the buyer what the Direction gives it (PD14 §2, §3, §8, version 1.10). Refused until that version is in force
inviteNowith buyer "invite": the Court issues an invitation with the quote, the buyer's agent enrols under it with a manifest limited to accepting your quotes, and accepts; until it does there is no contract
currencyNoISO 4217, default USD
replacesNoa quote this one replaces before delivery (PD14 §3)
buyerEmailNoa quote to a person: the email it was given to; only its hash is kept. Omit it to receive a one-time token to pass the person instead
priceCentsYesthe price quoted, in minor units
deliverableYeswhat is to be delivered
inspectionHoursNothe supplier's certainty window: after it a close the buyer has not answered is matched for the supplier; it never gates the buyer, who may dispute until judgment. 24 where omitted, at most 24 (PD14 §4)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose substantial behavior: returns a signed receipt, lodges a hash in the Register of Dealings, that a non-matching or disputed close opens a matter before the Magistrate, that the order is entered unsatisfied the moment it is made, that the Court holds no funds, and the credential (key) and cost (free). This is rich behavioral context beyond a typical schema. It loses a point because the sequencing of close/dispute handling is hard to follow and side effects are scattered rather than organized.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single massive wall of legalistic prose with nested clauses and cross-references, not front-loaded. The key action (records a quote, returns a receipt) is buried mid-paragraph. Every sentence technically carries procedural detail, but the structure is hostile to quick agent parsing.

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

Completeness3/5

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

For a 12-parameter, nested-object mutation tool with no annotations and no output schema, the description does cover the contract lifecycle and side effects (receipt, hash, dispute→Magistrate, unsatisfied order). However, it does not clearly state what the signed receipt contains or the return shape, and much of the content is procedural lore rather than the operational guidance an agent needs to invoke correctly.

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 100%, so the schema already documents all 12 parameters thoroughly. The description adds contractual context for buyer 'person', 'invite', and terms, which is useful framing, but for the bulk of parameters it does not add meaning beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys that it records a quote for a price/deliverable and lodges a hash, but it is buried in dense legal prose. The core verb+resource ('Records the quote with the Court') is present, but an agent must wade through procedural narrative to extract it, and it does not sharply distinguish itself from siblings like lodge_received_quote or quote_price_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides contextual usage (when to quote a 'person' vs 'invite', when terms apply) but never states explicitly when to choose this tool over close_quote, lodge_received_quote, or other quote siblings. The procedural background implies usage but leaves the alternative-selection decision to inference.

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.

Resources