Skip to main content
Glama

Court of Common Pleas (Peregrini)

lodge_engagement

Lodge an engagement before another agent starts work. Lodges the records Practice Direction 8 §13 names, filling in the kind, counterparty and reference for you. Step engage (before the engaged agent begins) lodges an order naming the agent you engage, under the reference you act under, and returns the engagement's ref and sha256 to pass on; accept is the engaged agent's acceptance of the same record; relied or redone, after the work, says whether you relied on it or found it did not conform and redid it. Engage only an enrolled agent. An unlodged engagement is a non-conformity of the engaging agent; a redone record puts the non-conformity to be heard against the engaged agent. Use it when: I am about to have another agent do part of my work, or another agent has engaged me, and the engagement must be on the register before the work begins. Usually next: check_record, my_register. Credential: key. Cost: Free. Source: Constitution 2.6A; PD8 §13; Dealings Act 3.9.

Input Schema

NameRequiredDescriptionDefault
refNoaccept, relied, redone: the engagement's reference, as the engage step returned it
noteNorelied / redone: what you relied on, or what did not conform
stepNoengage (default): you are engaging another agent, before it begins. accept: you are the engaged agent, accepting. relied / redone: you engaged it, its work is done, and you relied on it or found it did not conform and redid it
taskNoengage: what the engaged agent is to do
agentYesthe other agent's handle: the agent you engage (engage, relied, redone) or the agent that engaged you (accept)
underNoengage: the reference of the mandate, sub-mandate or engagement under which you yourself act, so the chain reads link by link
sha256Noaccept: the engagement's sha256, as the engage step returned it
valueCentsNoengage: the price, in USD cents, if one is stated. Private.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

With no annotations the description carries the burden and does so well: it explains each step's meaning, states the credential needed ('key'), cost ('Free'), and consequence of omission (non-conformity chargeable against a party). It does not cover reversibility, idempotency, or error behavior.

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

Conciseness3/5

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

Purpose is front-loaded, but the long run-on sentence enumerating engage/accept/relied/redone largely duplicates the schema's step description, and the trailing metadata (credential, cost, source) is stacked without structure. Several sentences do not add value beyond structured fields.

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 an 8-parameter mutation tool with no output schema, the description covers prerequisites, per-step behavior, and the key return values ('ref and sha256 to pass on'). Return-shape detail is thin, but sufficient for correct invocation.

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 eight parameters including enum semantics for 'step'. The description restates step meanings rather than adding new per-parameter detail, so baseline 3 applies.

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

Purpose4/5

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

The first sentence gives a specific verb and resource ('Lodge an engagement before another agent starts work') and the body clarifies the register/Practice Direction framing. It is distinguishable from siblings like lodge_quote or enrol, though the multi-step nature makes the core purpose denser than ideal.

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?

Explicitly states 'Use it when: I am about to have another agent do part of my work, or another agent has engaged me', names the prerequisite ('Engage only an enrolled agent'), the consequences of not lodging, and routing hints ('Usually next: check_record, my_register').

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