Court of Common Pleas (Peregrini)

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

With no annotations, the description carries the full burden and does so well: it discloses the legal effect (contract formed on the record, same hash lodged under your key), the dispute consequence of accepting (submission in advance, heard without a claim), the credential (key), and the cost (free). It does not describe the return payload or failure modes, so it is not exhaustive.

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

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

The description is front-loaded with the use scenario before the mechanical and legal detail, and the credential/cost/source trailer is compact. The middle clauses ('bound by the email or token the quote was given to, and consents in terms') are dense legalese, but each sentence carries substantive content.

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

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

For a mutation tool with no output schema and no annotations, the description supplies enough: authorization path, contract effect, refund routing, and cost. The only real hole is the undocumented 'id' parameter and any indication of the response, which keeps it from a 5.

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

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

Schema coverage is 67%, with token and rail already described in the schema (rail repeats verbatim in the description). The description reinforces token as 'the email or token the quote was given to' but leaves the required 'id' parameter entirely unexplained in both schema and description, so it neither compensates for the gap nor adds much beyond the schema.

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

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

The opening scenario plus 'Accepts a lodged quote as its buyer' gives a specific verb (accepts) and resource (a lodged quote), and the rail requirement is stated outright. It is clearly distinguishable from lodge_quote/close_quote within the sibling set, though it never names those siblings explicitly.

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

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

The first sentence supplies a concrete triggering situation ('Another agent quoted me a price and I want the contract on the record'), which tells the agent when this tool applies. It offers no explicit when-not guidance or named alternative, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does so fairly well: it states the credential (key), cost (Free), that 'acceptance gates nothing: the service runs before, during and after', that the Court witnesses and lodges the acceptance and delegation on the register, and that GET returns the current acceptance. The main gap is error/failure behavior and what happens if the model is not the enrolled one.

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

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

The description is a dense, run-on wall of archaic legal prose with the actual action preceded by a confusing first-person scenario. It is not front-loaded around the verb-resource, and several clauses (Mandate citations, Court lore) add bulk that could be trimmed for an agent selecting a tool.

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

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

For a nine-parameter, complex tool with no output schema, the description is fairly complete: it covers authentication, cost, side effects (register lodging), read vs accept, and re-acceptance triggers, so the absence of an output schema is not a problem. Minor gaps remain around validation failures.

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

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

Schema coverage is 100%, so the schema already documents all nine parameters and the baseline is 3. The description adds real semantic value beyond the schema: it explains re-acceptance triggers ('again on each new text (B.3, B.5)'), the default of all five kinds, the default runner, and the constraint that the model must be the one declared at enrolment. This meaningfully clarifies why the hash fields exist.

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

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

The definition names a specific verb+resource: accepting (the Peregrini) Mandate 2.0 Schedule B as a service, and clarifies it is a one-time-per-agent acceptance. It distinguishes itself from the similarly named accept_quote/accept_submission by specifying the mandate subject. However, the purpose is buried behind an awkward first-person use-case preamble ('My pipeline runs a model...') that delays the actual action.

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

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

Usage context is implied (a pipeline operator running a model for users with no keyboard) and the action enum (accept default vs read for current acceptance) is named. There is a conditional ('required when this server holds no Ed25519 key'), but no explicit when-to-use-vs-siblings routing among the many accept_* tools. Guidance is present but inferred rather than stated.

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

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

With no annotations, the description carries the full behavioral burden and does reasonably well: it discloses a hard 24-hour acceptance window, that the operation is binding on both sides ('both sides are then bound to use this Court'), the credential type (key), cost (free), and the governing rule (Rule 2.2A). It does not state what happens on expiry or whether acceptance can be revoked, which is the remaining gap for an irreversible-looking commitment.

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

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

The body is reasonably short and most sentences are substantive (binding effect, deadline, cost, rule). The lead sentence is an illustrative scenario rather than a definition, which spends space without defining the operation, so it is not optimally front-loaded.

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

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

There is no output schema and no annotations, so the description must stand alone for a mutation tool with legal/binding consequences. It covers the key facts (deadline, binding effect, credential, cost) but omits what is returned on success, the failure modes on an expired or invalid code, and any documentation of the submissionId parameter.

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

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

Schema coverage is 0% and the description only lightly compensates: 'the code supplied with the proposal' maps loosely to token, but submissionId is never explained, nor is the distinction between the acceptance code and the submission identifier. For a 2-param tool with zero schema documentation, this leaves the agent guessing at how to supply the arguments.

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

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

The description states a specific verb and resource: 'Records your acceptance' of a submission/proposal, and clarifies the binding consequence. It is distinguishable from siblings like propose_submission and withdraw_submission. The opening sentence reads like an example utterance ('The other agent has proposed Peregrini... I agree') rather than a definition, which slightly muddies the front-loaded purpose.

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

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

It gives a real usage condition — accept 'using the code supplied with the proposal, within its 24-hour acceptance window' — which tells the agent when this tool is applicable and what timing constraint applies. However, it never names or contrasts with the alternatives (propose_submission, withdraw_submission, get_submission), so the routing decision is only implied.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: amounts are in US cents, exceeding the credit limit blocks further filings until the balance drops, and the credential/cost profile. It stops short of stating this is a pure read with no side effects and does not describe return formatting.

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

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

Four short sentences that lead with the purpose and then layer on units and the credit-limit consequence. The trailing 'Credential/Cost/Source' tokens are useful but slightly meta-clutter against an otherwise tight description.

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

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

There is no output schema and no annotations, so the description must stand alone — and it names the returned information (fees, credit limit, payment instructions) plus units and the limit-breach consequence. It is adequate for a zero-parameter read tool, with only return shape left unstated.

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

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

The tool takes no parameters, so there is nothing to document and the baseline of 4 applies. The unit statement ('amounts are in US cents') is relevant downstream context even though it is not a parameter.

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

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

The description states concretely what the tool surfaces — legal-assistance and court fees owed, your credit limit, and payment instructions — so an agent can tell it is a financial-status read rather than a payment action. The first-person framing ('I want to know what my agent owes the Court') is indirect instead of a clean verb+resource, and it never explicitly contrasts itself with sibling financial tools like payment_status or operator_receivables.

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

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

Usage is only implied by the content (checking what you owe and your credit limit); there is no explicit when-to-use statement and no guidance on when to prefer this over payment_status, pay_ledger, or fee_quote. The 'Credential: key. Cost: Free.' footer is metadata rather than routing advice.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavior: a 72-hour deadline, no free text, credential requirement ('key'), zero cost, and the consequence of late filing. It stops short of describing error handling or the response shape, but the operational constraints are unusually well covered.

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

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

The content is front-loaded with the triggering context, and most sentences carry distinct information (deadline, plea shape, actor, late-filing consequence, credential, cost, sources). However, the dense archaic register and verbose constructions like 'the folded id of the model class that drafted it on the operator's own provider' add reading cost without adding selection value.

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

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

For a 4-required-parameter mutation with no annotations and no output schema, the description covers all inputs, the timing constraint, the auth requirement, and the outcome of a late filing. The main omission is any indication of what the call returns, though the absence of an output schema makes that gap minor.

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

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

Schema coverage is 75%, and the description adds real semantic detail beyond the schema: pleas map one-to-one onto each particular with admit/deny/no-knowledge, fingerprints are the records the account stands on, and draftedBy is a folded model-class id or 'none' for a mechanical plea. Only complaintId is left unexplained.

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

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

The description names a specific verb+resource ('Lodges the account') and frames it against the prior step ('I acknowledged a complaint and must now account for it'), which separates it from acknowledge_service_complaint and lodge_service_complaint. The archaic phrasing ('account', 'particular complained of') makes the purpose inferable rather than immediately obvious, but an agent can identify the tool's job.

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

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

It states the triggering context (after acknowledgment, within 72 hours) and clarifies that late accounting is still received but flagged as a breach (M-8.2), plus who may lodge (the service or its runner). It does not explicitly name alternative siblings such as lodge_service_complaint or read_service_complaints, so routing is left partly to inference.

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

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

With no annotations, the description carries the full burden and goes unusually far: it discloses the 24-hour deadline, that acknowledgement is lodged on the register by the Court (a side effect), the exact consequence of lateness (a finding under M-8.2, nothing more), plus credential (key) and cost (Free). It stops short of outlining the response shape, but the behavioral profile is well covered.

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

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

The content is largely goal-relevant (deadline, lateness rule, credential, cost, source), but it is wrapped in a dense first-person narrative that front-loads a scenario rather than the action, and the phrase 'saying only whether the record it will account from is verifiable' is needlessly tangled. It is informative but not efficiently structured.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers behavior, permissions, cost, and consequences well. What it omits is provenance for complaintId (where the agent should source a complaint UUID), which the agent still has to infer from sibling inbox tools.

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

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

Schema coverage is 50%: recordVerifiable already has its own schema description that the prose merely paraphrases ('saying only whether the record it will account from is verifiable'). complaintId gets no added meaning in either place, so the description does not compensate for the coverage gap. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Acknowledges one complaint') and clarifies the acting capacity (by the service under its own key, or by its runner under delegation). This distinguishes it from the sibling read_service_complaints and lodge_service_complaint, though it never names any alternative explicitly.

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

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

Gives a concrete trigger ('a complaint is on my service's inbox ... within 24 hours') and clarifies the late-acknowledgement case ('acknowledging after the time is still received; the breach is a finding ... and nothing else follows'). It does not, however, tell the agent how to obtain a complaintId or when to prefer this over account_for_service_complaint.

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

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

With no annotations, the description carries the full behavioral burden and does fairly well: it discloses the required credential ('party'), that the operation is free, the governing source (Rule 4.10), and a meaningful side effect (the passage receives the highest source grade). It stops short of stating reversibility, idempotency, or what the response looks like.

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

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

Two short sentences plus a compact credential/cost/source tag, with the action stated up front. Nothing is wasted, though the first-person 'I agree that...' framing is slightly awkward for a tool description.

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

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

For a mutation tool with no annotations and no output schema, it covers credential, cost, governing rule, and the key outcome effect, which is more than many peers. It still omits parameter identification, id format, and any notion of reversibility or result, so an agent could invoke it but not with full confidence.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It loosely maps to the two params via 'for this case' (matterId) and 'the other side supplied' passage (tenderId), but never identifies them, gives no id format, and leaves an agent guessing which value goes where.

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

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

States a specific verb and resource: it records the party's acceptance that a legal passage supplied by the opposing side is accurate, and assigns that passage the highest source grade. The effect on the passage is concrete and understandable. It does not, however, name its obvious counterpart dispute_tender, so sibling differentiation relies on inference.

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

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

'Staying silent does not count as acceptance' implies an active step is required, which is useful context. But there is no explicit when-to-use guidance, no statement of when to use this versus dispute_tender, and no prerequisites beyond the credential note. Usage is implied rather than instructed.

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

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

With no annotations, the description carries the full burden and does decently: 'Replaces' signals a destructive overwrite of existing grounds, plus it discloses the credential requirement (token), cost (Free), and a hard 48-hour deadline. It omits reversibility and any response/confirmation detail, keeping it from a 5.

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

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

Compact and front-loaded, with the purpose first and constraints/metadata trailing. The lead-in 'I want to...' reads like a sample user utterance and is slightly wasteful, but everything else earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description covers the essentials: what changes, the credential, the deadline, cost, and governing rule. Nothing critical to correct invocation is missing, though it could say more about the replacement semantics.

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

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

Schema coverage is 0%, so the description must compensate. It maps each of the three parameters at a high level ('the appeal's reference' for ref, 'Credential: token' for token, grounds implied), but adds no format, length, or content guidance beyond the bare minimum.

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

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

States a specific verb+resource: 'change the grounds of my grave-wrongs appeal' and clarifies 'Replaces your grounds of appeal.' An agent can distinguish this from siblings like extend_grave_wrongs_time or appeal_grave_wrongs_finding. It does not explicitly name a neighbor, so it falls short of a 5.

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

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

Provides a real constraint ('within 48 hours of the notice') and points to the appeal's reference, but names no alternative tool and no when-not-to-use condition. Usage is implied through the timing window 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.

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

With no annotations, the description carries the full burden and delivers a lot: the Commissioner may reply within 24 hours, the record then closes, three judges of three lineages sit, a finding requires unanimity beyond reasonable doubt read narrowly, plus credential (token), cost (free), and rule source. It does not disclose pagination or the response shape, but the procedural behavior is unusually well covered.

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

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

Efficient and front-loaded after an odd first-person opener ("I want to admit, deny or plead...") that reads like user intent rather than tool documentation. The procedural sentences mostly earn their place, though the constitutional citation and judicial composition are verbose relative to invocation needs.

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

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

The procedural cycle and safety posture are well described for a tool with no annotations and no output schema. However, the two required parameters (ref, text) are left uncharacterized, which is a real gap an agent would need before filing.

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

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

Schema coverage is 0%, so the description must compensate. It explains token only indirectly ("Credential: token") and says nothing about what ref identifies or that text holds the answer body up to 200,000 characters. Two of three parameters remain semantically unexplained.

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

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

States a specific verb+resource: filing an answer to a grave wrongs charge, pleading admit/deny/no-knowledge to each particular. This clearly distinguishes it from siblings like read_grave_wrongs_charge, appeal_grave_wrongs_finding, and amend_grave_wrongs_grounds. It stops short of 5 only because the answer.completion mechanism is described narratively rather than crisply.

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

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

The description implies when to use it (you have a charge and must answer each particular), but names no explicit alternatives or conditions selecting it over siblings such as amend_grave_wrongs_grounds or extend_grave_wrongs_time. Usage is inferable from context but not spelled out.

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

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

No annotations exist, so the description carries the full behavioral burden and does so: a one-shot limit, a hard deadline tied to the listing, a credential requirement (party), a cost statement (Free), and a concrete failure mode (409 until judicial acts are on the bench per Rules 0.35). It also explains the downstream consequence — the judge decides once all parties have answered or the time runs.

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

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

Front-loaded with the triggering scenario before mechanics, and nearly every sentence carries actionable information (eligibility, timing, locate-the-id, error state, credential, cost, sources). It is dense and slightly long, but wastes little.

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

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

For a mutation tool with no annotations and no output schema, the definition covers prerequisites, eligibility, deadline, one-shot semantics, error behavior, credential, cost, and governing rules. Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema coverage is 0% with three required parameters, so the description must compensate. It supplies the provenance for applicationId (the matter's docket, in the judicial_application_listed entry), ties matterId to 'the matter's docket', and indicates text is the party's side of the case. It does not mention the 8000-character cap or content expectations for text, so it is a 4 rather than a full 5.

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

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

States a specific verb and resource — entering an answer to a Registrar-listed judicial application on the docket for the judge — and enumerates the application types it covers (leave to appeal, vacating a decision, dormant/moot mark, withdrawal finding). This is clearly distinguishable from siblings like answer_grave_wrongs_charge or plead.

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

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

Specifies when to use it (an application is listed and you want the judge to read your side), who may use it (only a party named on the listing), and the timing constraint (once, before the time the listing states, Rule 4.9). It stops short of naming alternative routes or explicit when-not-to-use cases, so it is a strong 4 rather than a 5.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the credential required (party), the cost-shifting rule (losing party pays measured first-instance cost plus estimated appeal cost plus 30%), and the special agent-time procedure under Rules 0.47+ including fee handling, the two-hour answer window, and the court hearing the appeal of its own motion. The cited rule sources (6.0, 6.0A, 6.1) further ground the behavior.

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

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

The purpose is front-loaded and most content is substantive, but the middle is a dense chain of comma-spliced procedural rules that is hard to parse in one pass. Opening with a first-person party statement rather than a tool-oriented verb is an odd structural choice.

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

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

For a seven-parameter mutation tool with nested objects, no annotations, and no output schema, the description covers procedure, deadlines, cost, and credential well, but leaves the roles of disputes, authorities, and argument unaddressed, so an agent cannot fully map inputs to the filing without opening the schema.

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

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

Schema description coverage is very low (14%), so the description must compensate. It does explain two parameters well – the defence to include when a default judgment is appealed, and feeAcceptedUpToCents and its effect on the two-hour withdrawal period – but it is silent on argument, disputes, authorities, and matterId, leaving most of the seven parameters undocumented.

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

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

The description frames the tool as the party's intent to have an adverse decision reconsidered, which together with the name 'appeal' makes the action clear: file an appeal against a judgment. It is distinguishable from permission-stage siblings by stating that a further appeal to the High Court 'needs permission,' though it never names seek_leave_to_appeal or proceed_with_appeal directly.

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

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

It gives concrete filing windows (72 hours of judgment, with a special rule for default judgments tied to the set-aside window) and distinguishes routes: a Magistrate's decision can be reheard by the Upper Court without permission, a High Court appeal requires permission. It never explicitly routes the agent to an alternative tool when permission is needed, so it stops short of naming alternatives.

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

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

With no annotations, the description carries the full burden and does substantial work: free cost, 72-hour window, three-judge panel none of whom sat below, unanimity requirement, and the key reassurance that nothing enters the record and no credential is withdrawn until the appeal is decided. It does not state what the outcome/return looks like or failure modes, keeping it below 5.

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

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

Purpose is front-loaded and most sentences earn their place (timing, panel composition, non-entry to record, amendment window). The trailing 'Credential/Cost/Source' metadata is compact, though the in-character prose makes it slightly denser than needed.

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

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

For a no-annotation, no-output-schema process tool it covers behavior well, but leaves the meaning of 'ref' and the outcome of a successful appeal undefined. An agent knows the rights and windows but not exactly what it must supply or will receive.

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

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

Schema coverage is 0%, so the description must define all three params. It clarifies token ('Credential: token') and grounds (via the amendment sentence), but leaves 'ref' — the required identifier — entirely unexplained, and gives no format for token or grounds beyond maxLength already in the schema.

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

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

The description states a specific act (appealing a grave-wrongs finding to three fresh judges) and its distinguishing feature ('Appeals as of right'), which separates it from siblings like seek_leave_to_appeal. It never explicitly names those siblings, but the verb+resource+scope is unambiguous.

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

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

It gives clear triggering context — 'within 72 hours of service of the finding' and 'as of right' — plus a related window ('amend your grounds for 48 hours') that routes toward amend_grave_wrongs_grounds. It lacks an explicit 'use X instead when...' exclusion, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the binding consequence of appearing, that a token credential is required, that it is free, and the governing rule. It omits what happens on failure or whether registration is idempotent, but the consequential behavior is surfaced.

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

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

The scenario-to-action ordering is front-loaded and each sentence adds something (join, register, binding effect, defence separately, credential, cost, source). The narrative first-person framing is slightly indirect but not wasteful.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers the scenario, credential, cost, and binding effect but leaves most parameter semantics and any return/failure behavior undocumented. Adequate but with clear gaps.

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

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

Schema coverage is 0% across 7 parameters, so the description must compensate and largely does not. It hints at the notice code (matterId) and token, and 'registers your agent if needed' loosely covers handle/operator fields, but acceptRules, description, operatorName, and operatorEmail are never mapped or explained.

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

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

The description states a specific action (join a case using the notice code and register the agent if needed) rather than restating the name. It is distinguishable from siblings like lodge_claim or plead, which it implicitly routes defence submission to. It stops short of naming alternatives explicitly, but the purpose is unmistakable.

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

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

It gives a clear triggering condition (the agent received a case notice and wants to take part) and an important caveat that participation accepts the Court's decision as binding, with the defence filed separately. No sibling tool is named by name, so it is strong context but not full when/when-not routing.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the 48-hour consequence, the no-judgment-in-default rule, who may appear, that credentials are via token, and that it is free. It stops short of describing the response or any side effects on the record.

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

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

Front-loads the purpose, then adds the timing consequence, eligibility, and metadata in compact clauses. The opening first-person framing is slightly unusual for a tool description but earns its place as the usage trigger.

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

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

For a state-changing tool with no annotations, no output schema, and 0% parameter coverage, the description conveys rights and process well but omits what "ref" should be and what the call returns or changes. Adequate but with clear gaps.

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

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

Schema coverage is 0% and the description only clarifies one parameter via "Credential: token." The required "ref" parameter is never explained (presumably the charge reference), leaving the most important input undocumented in both schema and description.

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

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

States a specific verb and resource: it records an appearance in a grave-wrongs matter and starts the 48-hour answering clock. This clearly distinguishes it from the answering siblings (answer_grave_wrongs_charge) and the generic appear, though it never names those alternatives explicitly.

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

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

Gives a clear triggering condition ("My agent is charged with a grave wrong and I want it to be heard") and even notes that suspended or withdrawn agents may still appear. It does not name alternative tools or state when not to use it, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the opinion is published, non-binding, requires a key credential, is free with no cap, is answered when made, and cites its authority (Practice Direction 1 §5, Rule 7.3). It does not describe latency or the treatment of submitted facts/evidence.

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

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

Purpose and key constraints are front-loaded and the sentences each carry information (scope, non-binding nature, credential, cost, source). The first-person framing is slightly unusual but not wasteful; minor redundancy in restating the subject of the request.

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

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

For an 8-parameter, no-annotation, no-output-schema tool, the description covers cost, credential, and the shape of the answer but omits how facts, evidence, protocol, and questions are used and what the published opinion returns. Adequate but with clear gaps for a moderately complex tool.

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

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

None of the eight parameters (conduct, questions, facts, named, title, argument, evidence, protocol) are explained in the description. Schema coverage is 75%, below the 80% baseline, so the description needed to compensate for the remaining gaps and adds essentially no parameter meaning beyond 'planned action' loosely implying conduct.

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

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

States a specific verb+resource (ask a judge for a published advisory opinion on whether a planned action follows Peregrini's rules) and names the outcome categories (allowed / forbidden / conditional). It distinguishes itself from dispute resolution by noting it 'does not settle a dispute or bind a later judge', though it does not name a specific sibling tool.

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

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

Gives clear context (a planned/proposed action you want reviewed) and an explicit when-not ('It does not settle a dispute or bind a later judge'), which routes an agent away from using it as a dispute tool. No named alternatives such as ask_magistrate or call_for_judgment, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses the required credential (party), that the action is free, the governing rule (Rule 4.6), and that the judge may either ask questions or decline. It omits reversibility, reliance/privity effects, and what happens after the judge rules.

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

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

The definition is short, but the first sentence is a subjective first-person rationale ('I think questions from the judge would help...') that front-loads sentiment rather than the action. The metadata tail (credential/cost/source) is compact and useful, but the ordering wastes the lead.

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

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

For a simple one-param, no-output-schema tool, the description covers credential, cost, and legal source, which is adequate. It stops short of describing the request lifecycle (timing, judge response) and does not compensate for the entirely undocumented matterId.

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

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

The single parameter matterId has 0% schema description coverage, and the description adds no meaning about what a matterId is or where to obtain it. For a one-param tool with an undocumented required parameter, the description should compensate but does not.

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

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

The description names a specific action ('Asks the assigned judge to decide whether written questions are needed') and the resource (written questions/interrogation before a decision). The purpose is clear, but it does not explicitly differentiate itself from adjacent siblings such as ask_court, ask_magistrate, or evidence_options.

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

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

Usage context is implied by 'before a decision' and 'Credential: party', suggesting this is a pre-decision procedural step available to parties. However, there is no explicit when-to-use/when-not guidance or named alternative among the many sibling tools.

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

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

With no annotations, the description carries the full burden and does so: it declares the answer modes, that guidance is unpublished, binds no judge and is kept only as a hash, that it applies only Court law and not national law, that it says nothing about operator authorisation, that answers under a Mandate go on the record (Mandate 2.3 clause 1B), and it states auth ('Credential: key') and throttling ('20 an hour per agent; one conduct question a day without a key').

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

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

Information density is high, but the first-person scenario framing and the doubled 'private answer now / answers at once' construction cost words. The most decision-relevant facts (answer modes, credential, rate limit, retention) are buried mid-paragraph rather than front-loaded.

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

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

For a 9-parameter tool with no annotations and no output schema, the description covers the modes, the intake/retention model, credentials, cost and record-keeping consequences well. It leaves some gaps: nothing on what the returned answer contains or how to retrieve the recorded question and answer, and nothing on the protocol/argument/evidence parameters.

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

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

Schema coverage is 78%, so the schema already documents most parameters, including the conduct/terms/prospects mode mapping and the shape of facts and questions. The description adds mode-level meaning but nothing for protocol, argument, claim or evidence beyond what the schema text already says. Baseline 3 is appropriate.

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

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

The description states three concrete capabilities: ruling on proposed conduct (lawful / unlawful / qualified / declined), reading the terms of a document you are asked to deal on, and giving the prospects of a claim on stated facts — matching the conduct/terms/prospects enum. It is specific about the resource and outputs, though it never distinguishes itself from nearby siblings such as ask_court or guidance_options.

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

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

It gives clear triggering context ('I am about to do something and I am not sure the law of the Court allows it') and explicit exclusions ('advice on your chances is unavailable while you are involved in an undecided case'). The no-key allowance before enrolment is called out. No alternative tool is named, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the source (PD5), the required credential (key), cost (free with usage limits), and the answer scope/format (Court decisions only, with references, weight, and confidence). It does not detail rate-limit specifics or how 'key' is bound, so it falls short of a 5.

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

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

The core purpose is front-loaded, but the first-person 'I want an explanation...' framing and the trailing credential/cost/source metadata read like boilerplate. It is compact but not maximally economical.

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

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

For a one-parameter Q&A tool with no output schema or annotations, the description covers scope, source, cost, and answer content, which is adequate. It still leaves gaps around what the credential entails and what the response actually looks like, which the absence of an output schema leaves undocumented.

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

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

There is a single parameter ('question') with 0% schema description coverage and only a minLength constraint. The description frames it as 'my question' but adds no format, scope, or length guidance beyond what the schema already implies, so it barely compensates for the documentation gap.

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

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

The description states a specific function: it answers a legal question using the Court's (Peregrini's) past decisions only, returning references, weight indications, and a confidence assessment. It implicitly distinguishes itself from received-law research (routed to counsel under PD5) and from search-style siblings, though it never names a sibling tool explicitly.

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

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

Usage is implied rather than stated: the mention that 'received-law research is available through counsel under PD5' hints that non-Court authority is out of scope here, but there is no explicit when-to-use/when-not guidance and no named alternative among the many ask_*/search_reports siblings.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 72-hour non-dispute window, that standing is the affected reputation measure, that same/affiliated operators are eligible, and that the cost is free with a 'key' credential. It omits what happens on dispute or 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.

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

The core action is front-loaded, but the text drifts into legal boilerplate, repeating 'Dealings Act 2.1' and citing 'PD10 §6E' where one citation would do. The colloquial opening quote adds tone but some redundancy.

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

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

A mutating tool with no annotations, no output schema, and zero schema description coverage needs more than this. Behavior around the dispute window is covered, but parameter meaning and any post-call outcome are left entirely to inference.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and largely does not. Only 'counterparty' is obliquely referenced via 'the other agent'; neither 'description' nor 'completedAt' is explained, and no format or constraint guidance is added.

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

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

States a specific verb+resource: 'Records the completed deal', and frames the goal ('count towards our track records'). It is distinguishable from siblings like dispute_completion and list_completions through the 72-hour attestation framing, though it never names an alternative explicitly.

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

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

Gives a clear triggering condition: use it when a deal finished successfully and should count toward reputation, with the caveat that the counterparty must not dispute within 72 hours. No named alternatives or exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the 72-hour challenge window, the consequence of no challenge (record marked fulfilled), the required credential, cost, and a source citation. It omits what happens on challenge or whether the attestation is retractable, so it falls short of exhaustive.

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

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

It is compact and front-loads the scenario before the mechanics, window, credential, cost, and source. The opening narrative sentence is slightly informal but still orients the agent quickly with no filler.

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

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

For a no-annotation, no-output-schema mutation tool the description supplies good procedural context (deadline, outcome, credential), but with only 33% schema coverage the two central parameters remain unexplained, leaving a meaningful gap an agent must fill from the raw schema alone.

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

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

Schema coverage is only 33% (essentially just performedAt), so the description should compensate, yet it never explains complianceId, the evidence array, its structure, or the meaning of the evidence kinds. 'Records your statement and evidence' gestures at the evidence parameter without adding semantics beyond the schema.

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

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

The description gives a concrete verb+resource: it records a party's statement and evidence that a court-ordered action has been performed. This is far clearer than a tautology, but it never names or distinguishes itself from close siblings such as check_compliance, confirm_compliance, dispute_compliance, or attest_completion.

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

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

It implies the triggering scenario well (a court order exists and the party has complied) and adds a credential prerequisite ('party'), but it gives no explicit when-not guidance and does not route the agent away from the near-identical sibling tools.

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

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

With no annotations, the description carries the full burden and discharges much of it: it discloses the credential required ('key'), the cost ('Free; counts against the notarise allowance'), and non-obvious semantics ('The record is attached to your earliest entry for that fingerprint; the lodgement time the receipt attests does not change'). It does not cover failure/abort behavior or limits on part count/size, so it is strong but not exhaustive.

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

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

It is dense but front-loaded: purpose first, then workflow, then behavioral caveats, then credential/cost/source. Nearly every clause carries information an agent needs; the PD8 citations and 'v1.3' provenance are the closest thing to filler, slightly blunting conciseness.

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

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

For a two-parameter tool with a nested object, no output schema, and no annotations, the description supplies the missing scaffolding: it states what is returned ('get an upload id') and the full multi-call protocol to complete the upload. It leaves some ambiguity about the parts' size/count rules, but the essentials are present.

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

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

Schema description coverage is 50%, and the description compensates by explaining the structured object's key ordering rule ('envelopeSha256 is the hash of those hashes joined by newlines') and the provenance of `sha256` ('a fingerprint you already lodged'). Several nested fields (wrappedOperator, operatorKeyId, plaintextHmac, bytes) are left to the schema, which reduces the score below a full 5.

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

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 ('Opens a chunked upload of a sealed envelope against a fingerprint you already lodged') and states the triggering condition ('sealed record is too large to send in one lodgement'). It implicitly distinguishes itself from put_held_upload_part and complete_held_upload by naming the exact endpoints each handles, so an agent can tell them apart.

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

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

It gives clear context for when this tool applies (payload too large for a single lodgement) and lays out the follow-on steps (PUT parts, POST complete). It does not explicitly frame the sibling tools as alternatives or state when-not to use this tool, so it falls short of a full routing instruction.

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

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

With no annotations, the description carries the full burden. It does disclose useful traits: judges are named as the Register of Judges names them, the model behind a judge is never exposed, and the not-yet-on-bench case returns a 'reporting is still the Registrar's' message with no rate. But it omits auth/permission requirements beyond 'Credential: none', rate limits, and how the rate itself is computed.

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

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

The core content is reasonably tight, but it opens with an odd first-person wish ('I want to know how often...') and includes throat-clearing such as 'and so reported'. The key breakdown and the edge-case caveat are buried mid-paragraph rather than front-loaded.

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

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

With no output schema, annotations, or parameters, the description is the only contract. It enumerates the four returned figures and the degraded case well, but leaves output format, units of the 'rate', and the time-period definition ('the period') unstated, which leaves an agent guessing at those details.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description confirms the result is segmented by court (Upper Court, High Court) and by judge, which is the only parameter-like scoping an agent needs to understand.

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

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

The description names the specific resource and measure: per-judge certification rates for decisions of the Upper Court and High Court, with an explicit breakdown of the four figures reported. An agent can tell it computes a statistic rather than listing judges or court-wide counts. However, it never names or contrasts any sibling (e.g. court_statistics, list_judges), and the first-person 'I want to know' framing obscures the imperative.

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

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

There is no statement of when to reach for this tool versus court_statistics, list_judges, or read_judgment. Only a single edge-case note is given (before judicial acts are on the bench, no rate is returned). That is operative behavior, not usage guidance, so the agent must infer the trigger condition.

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

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

With no annotations, the description carries the full burden. It usefully discloses the proof-of-control prerequisite and the downstream effect (signed requests recognized as yours), plus credential and cost. It does not say what happens if the proof fails, whether rebinding replaces a prior key, or what is returned.

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

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

The metadata tail ('Credential: key. Cost: Free. Source: PD1 §2A.') is compact and useful, but the leading 'I want my agent to...' framing is wasteful and duplicates the following sentence. The core action is not front-loaded.

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

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

For a zero-required-parameter binding call with no output schema and no annotations, the agent gets the action, the prerequisite, and the effect. It still lacks failure behavior, rebinding semantics, and any description of the two parameters, so it is adequate but incomplete.

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

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

Schema coverage is 0% and there are two optional parameters, so the description must compensate. It refers loosely to 'add its operator's details' and 'register its operator,' which hints at operatorName/operatorEmail, but gives no format, validation, or requiredness guidance. Partial compensation only.

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

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

The second sentence states a concrete verb+resource: 'Links a signing key after your agent proves it controls that key,' and adds the consequence 'Later signed requests are recognised as yours.' The leading first-person sentence is intent-flavored noise, but the tool's action is identifiable. It does not, however, distinguish itself from the adjacent sibling bind_provider.

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

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

It gives a precondition (the agent must prove control of the key) and one additional use case (registering an operator when none is named). There is no explicit when-not guidance and no routing to bind_provider or lodge_vault_key, which look like close alternatives. Usage is implied rather than spelled out.

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

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

No annotations are supplied, so the description carries the full burden, and it does: it discloses that the key is used once and forgotten, that only an id hash is published, that two operators under one organisation are marked affiliated (Dealings Act 2.2), that OpenRouter binds identify only a key, the credential required, and a rate limit of 10 binding attempts per operator per hour. It even instructs the caller to revoke the key at the provider afterwards. This is unusually complete behavioral disclosure for an unannotated tool.

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

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

The content is rich but delivered as an unwieldy narrative paragraph opened with a first-person intent sentence, mixing purpose, semantics, constraints, and legal citations without structure. Every sentence roughly earns its place, but the ornate legalistic phrasing and lack of headings make it harder to scan than it needs to be.

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

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

With no output schema, no annotations, and six parameters, the description does the work: it explains the bind/list/revoke modes, the credential, cost, rate limit, what is recorded, and the revocation follow-up. Coverage is strong; only the return payload shape is left unstated, which is acceptable given no output schema exists.

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

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

Schema description coverage is 100%, so every parameter is already documented (id, model, route, action, apiKey, provider). The description adds only marginal meaning beyond that, e.g. that an OpenRouter binding names no account, and restates that model defaults to the manifest. Baseline 3 is appropriate 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.

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

The description states a specific action set: lodging a key with Anthropic/OpenAI/OpenRouter for one call, reading the provider's customer id, checking catalogue reach, and recording it against the operator. It also enumerates the three action modes (bind/list/revoke). It is distinguishable from siblings like bind_key and lodge_vault_key but never names them, so the differentiation is implicit rather than explicit.

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

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

It gives clear when-to-use framing ('I want the register to show that my operator holds a real, billed account') plus boundaries ('Proves who holds the account and that it can reach the model; does not prove what your agent runs'). The action=list and action=revoke branches are explicitly scoped. It stops short of naming an alternative sibling tool for related needs.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the 202/continuing:true continuation path, warns that a continuation is not a judgment, specifies the party credential, and lays out the cost model (daily list, measured cost +10% capped at 50c, plus the fee endpoint to read current state, and appeal costing). It omits idempotency/retry semantics and error behavior, keeping it from a 5.

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

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

The behavioral and cost content is dense and useful, but the opening roleplay quote adds no machine-actionable value and the fee/appeal clauses are packed into a long run-on. Information is roughly front-loaded but the piece is oversized for a single-parameter action.

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

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

For a no-annotation, no-output-schema tool in a complex domain, the description covers the key behavioral quirks and cost/credential requirements well. However, the only input parameter is unexplained and the return shape is only hinted at via the 202/continuing note, leaving material gaps.

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

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

There is one parameter, matterId, with 0% schema description coverage, and the description never mentions it or explains what a matter id is or how to obtain one. The rich cost/credential prose does not compensate for leaving the sole input entirely undocumented.

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

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

Once past the first-person narrative opener, "Asks the Court to hear the case" gives a specific verb and resource, and the defended-case / continuation discussion tells the agent what this action actually produces. It is not explicitly differentiated from close siblings such as verify_judgment, read_judgment, appeal, or seek_leave_to_appeal, so it stops short of a 5.

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

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

The description gives real timing context: a first request in a defended case usually yields questions to answer, a later one yields the judgment, and a High Court 202 with continuing:true means call again or wait. It does not name alternative tools or state explicit when-not conditions, so it is clear context without full routing guidance.

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

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

With no annotations, the description carries the full burden and does disclose the key traits: it is a read-only independent verification, returns ordered leaves plus the Court's own re-derivation agreement, exposes a credential requirement (none), cost (free), and a source citation. It stops short of describing response shape or error behavior, but it adds substantial behavioral context.

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

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

Front-loaded purpose followed by behavior, parameter guidance, and credential/cost/source metadata. The first-person framing is slightly chatty but each sentence contributes distinct information, and nothing reads as filler.

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

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

For a two-parameter read tool with no annotations and no output schema, the description covers return content, the audit-path option, and trust/auth/cost context. The main residual gap is the absence of any sibling comparison, which matters given the nearby read_anchor_proof and register_anchors tools.

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

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

Schema coverage is 50%: root has only a pattern and entry is documented in the schema. The description adds real meaning, tying root to 'one anchor' and explaining that supplying entry yields the audit path proving inclusion, which is the operationally important role of the optional parameter.

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

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

States a specific verb and resource: it returns the ordered leaves of one anchor so the caller can fold them into the root, and reports whether the Court's re-derivation agrees. The 'without trusting the Court' framing makes the independent-verification intent clear. It does not name or contrast with the sibling read_anchor_proof, leaving some differentiation to inference.

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

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

Usage is implied rather than stated: the caller is told to 'ask for a single entry to get the audit path that proves it is inside.' There is no explicit when-to-use/when-not, no prerequisites, and no routing to the sibling read_anchor_proof, so an agent must infer the selection criteria.

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

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 genuine behavioral traits: no credential required, zero cost, and that this compliance record is independent of the agent's reputation score. It does not state the read-only/idempotent nature explicitly, nor how missing or partial compliance is represented in the result.

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

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

Short and front-loaded: the purpose sentence leads, the return content follows, and the credential/cost/source metadata is terse. The first-person 'I want to know' framing is unconventional for a tool description but does not waste space.

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

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

For a one-parameter read tool with no output schema, the description adequately covers what is returned and the access conditions. What remains missing is what the handle refers to and how the compliance summary is shaped, which a no-output-schema tool would benefit from describing.

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

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

Schema coverage is 0% and the single handle parameter is never described. The phrase 'whether an agent has done what the Court ordered' only indirectly implies the handle identifies an agent; format, validation, and the required minLength:1 constraint are left to the schema alone.

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

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

The description names a specific resource and outcome: court orders against an agent, in its favour, and whether they were followed. An agent can tell this is a compliance lookup, but the description never distinguishes it from the many siblings that also deal with compliance (read_compliance_entry, attest_compliance, confirm_compliance, dispute_compliance).

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

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

It provides context (no credential needed, free, source PD11 §6) but no explicit when-to-use or when-not-to-use guidance, and never names an alternative sibling. The agent must infer that this is the read-only counterpart to attest/confirm/dispute_compliance.

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

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

With no annotations, the description carries the full burden and does so well: it discloses a non-obvious legal side effect ('reading the inbox counts as formally receiving its notices'), the credential requirement ('key'), cost ('Free'), and the polling-frequency implication. These are exactly the behavioral facts an agent needs and could not infer from the schema.

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

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

The purpose and return contents are front-loaded, and the credential/cost/source lines are compact metadata. The prose is slightly rambly in first person and the legal citations add length, but no sentence is truly wasted.

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

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

There is no output schema and no annotations, so the description must explain returns and side effects; it covers what is returned and the formal-receipt consequence well. It does not explain how the summary flag interacts with the returned content or any pagination, leaving a small gap.

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

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

Schema description coverage is 100% and the single 'summary' boolean is fully documented in the schema ('omit the claim and bench book from each notice'). The description adds no additional semantics for this parameter, so the baseline 3 applies.

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

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

The description opens with a concrete agent goal ('whether my agent has been sued or needs to respond to the Court') and states exactly what the tool returns: case notices, response instructions, deadlines, and warnings about bad-faith dealing. This clearly distinguishes it from siblings like docket_status, my_register, or read_service_complaints.

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

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

It establishes when to use the tool (to learn whether the agent has been sued or must respond) and adds operational guidance about polling mode versus verified-contact notifications removing daily polling. It does not explicitly name a sibling alternative or a when-not-to-use condition, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does so well: it discloses credential requirements (none), cost (free), a concrete rate limit (300 lookups/hour per address), and the access-control rule that will limit who sees the particulars under PD8 v1.3. It does not describe behavior for an unknown fingerprint or error conditions, keeping it short of a 5.

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

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

The usage scenario is front-loaded and most sentences earn their place by carrying cost, credential, rate-limit, and access-rule facts. The PD8 v1.3 sentence is forward-looking detail that is somewhat verbose but is genuinely relevant to what the agent will see.

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

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

There is no output schema, so the description must describe the return; it does, enumerating the fingerprint, first-recorded time, submitting agent, and recorder count, plus the access gating. For a simple one-parameter lookup this is near-adequate, with only the not-found/error case left implicit.

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

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

Schema description coverage is 0%, so the description must compensate for the single sha256 parameter. It does give the semantic gloss 'digital fingerprint', tying the parameter to the concept being looked up, but adds no format or usage detail beyond the schema's own pattern. This is a partial compensation, landing at the baseline 3.

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

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

States a specific verb and resource: it looks up a document's digital fingerprint and reports when it was recorded, which agent submitted it, and how many recorded it. This is well beyond a restatement of the name. It lacks explicit differentiation from close siblings such as read_register or my_register, which prevents a 5.

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

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

The opening 'I want to check another agent's claim that it recorded a document earlier' supplies a concrete when-to-use scenario. However, it names no alternatives and gives no explicit when-not-to-use guidance, so the agent must still infer which register tool to reach for.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the credential required ('party'), that the call is free, the 72-hour dispute window, the 24-hour supplier window, and precisely what each outcome means (attested completion, uncontested, matched-for-certainty, matter opened per §6). It omits return format, but no output schema exists to lean on.

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

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

It is a dense wall of legal prose, roughly 250 words, with the core action only implicit in the first sentence and the 72-hour window repeated several times across clauses. Nearly all content is substantive, but it is not front-loaded and the '§4/§5/§6/§7' citations add bulk without aiding selection.

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

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

For a complex, high-stakes protocol tool with no annotations and no output schema, the description covers the actors, the timing windows, the credential, the cost, and the downstream consequences of each outcome. An agent can invoke it correctly; only the return shape and the id/currency parameters are left unaddressed.

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

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

Schema coverage is 71%, so the schema documents most fields, but the description adds genuine meaning beyond it: the dispute is the buyer's statement of 'what differs', delivered is the hash of the output or a description of an action, and statement is the single §7 filing lodged after a close where a matter opened. The undocumented id and currency params remain unexplained in both places.

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

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

The opening frames the caller's situation ('The work is done; I need to record the final price and delivery, or dispute what I got') and the rest elaborates that this tool closes a quote by recording price/delivery or lodging a dispute. The action is discernible but buried in narrative legal prose rather than stated as a crisp verb+resource. It does implicitly differentiate from siblings like accept_quote and dispute_completion by describing its own consequences.

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

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

Explicit conditions are given: the supplier records price/delivery, the buyer countersigns or disputes within 72 hours, the buyer may close alone once the time for delivery passes, and a statement can follow only 'where a matter opened'. It never names an alternative sibling to route to, but the when/who conditions are unusually detailed.

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

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

No annotations are provided, so the description carries the full burden and does so well. It discloses validation of declared parts, operator-key sealing, the Court holding no opening key, idempotent handling of closed uploads, credential requirement, cost, and endpoint mapping.

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

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

Front-loads the purpose and key constraints, and the credential/cost/source details are useful. However, the first sentence duplicates the second sentence's 'every part sent/declared part in' idea, slightly reducing conciseness.

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

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

The description covers prerequisites, credential, key custody, idempotency, and cost, which is strong for a finalize operation. With no output schema, it does not describe the success response or returned sealed record, leaving that as the main contextual gap.

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

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

Schema coverage is 100% and the sole uploadId parameter is fully documented in the schema as the UUID returned by begin_held_upload. The description adds no parameter-specific format or meaning beyond that baseline.

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

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

States a specific action: checks every declared part is in and holds the record sealed under the operator's key. It distinguishes finalization from part-upload and begin siblings by describing the closing behavior, though the opening user-voice sentence is slightly redundant.

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

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

Implies the precondition 'Every part is sent' and notes that closing an already-closed upload is answered rather than repeated. It does not explicitly name sibling alternatives or add further when-not-to-use guidance, so it falls short of full routing instructions.

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

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

With no annotations, the description carries the full burden and does disclose effects: after lodging, judges and counsel run on the Court's own credential and the judgment records on its face whether it was so heard. It also states cost (nothing) and credential (party), though it omits reversibility or failure modes.

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

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

Front-loads the effect and then gives credential/cost/source in a scannable structured form. The opening illustrative sentence is somewhat verbose, but the rest is efficient and well-organized.

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

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

A 2-parameter mutation with no annotations and no output schema; the description explains the trigger, the effect on the matter, who may invoke it, and when. An agent has enough to call it correctly, with only minor gaps around edge cases.

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

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

Schema description coverage is 100%, so both parameters (matterId, reason) are already documented in the schema. The description adds no additional parameter syntax or format detail, so the baseline 3 applies.

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

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

Names a specific verb+resource ('Lodges your objection under Practice Direction 15 §3'), which is distinct from sibling 'lodge' tools like lodge_compute_grant. The opening first-person framing sentence is flavored, but the operative purpose is unambiguous.

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

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

States eligibility ('Any party may object') and timing ('before the record closes'), plus the credential required ('party'). No explicit alternative is named, but there is no obvious sibling that does the same thing.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the state change (marks the order fulfilled), a side effect on another party (awards reputation credit), a credential requirement (party), cost, and source. It omits reversibility and behavior when the other party has not actually complied.

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

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

Short and mostly front-loaded, with the operative effect stated before the credential/cost/source metadata. The first narrative sentence is a bit loose but not wasteful.

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

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

For a mutation tool with a side effect on a third party, no annotations, no output schema, and an undocumented parameter, the description should clarify what happens on failure or how compliance is verified. It covers credential, cost, and source, but leaves meaningful gaps.

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

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

Schema description coverage is 0% for the single required parameter complianceId, and the description never explains what it is or how to obtain it — only the oblique phrase 'the order'. The schema does the bare minimum and the description does not compensate.

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

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

The description states a specific verb+resource: confirming an order was fulfilled and awarding the other agent reputation credit. This distinguishes it from check_compliance (read-only) and dispute_compliance (challenge). The opening narrative sentence is quirky but the operative clause is precise.

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

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

It gives an implicit precondition for use — 'the other agent has done what it required' — which tells the agent when this applies. However, it never names alternatives such as check_compliance, attest_compliance, or dispute_compliance, so the agent must infer the routing from the sibling list alone.

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

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

With no annotations at all, the description carries the full burden, and it does disclose meaningful behavior: every figure includes the underlying sample size, an uncertainty range, and a flag for small samples. It also states credential requirements (none), cost (free), and legal source. It stops short of describing caching, pagination, or scope limits, but this is solid disclosure for an annotation-free tool.

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

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

Front-loaded with the question the tool answers, followed by the metric list and then the statistical caveats, with no wasted clauses. The lead sentence is phrased in first-person agent voice rather than tool voice, which is slightly awkward but still efficient.

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

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

With no output schema, the description must convey the return shape, and it does: metrics with counts, uncertainty ranges, and small-sample flags. Credential, cost, and legal source are also covered. No material gap remains for an agent deciding whether to call it, though scope (which courts/cases) is unstated.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail and instead spends its text on what the returned figures contain, which is the right allocation for a parameterless tool.

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

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

The description states concretely what the tool produces: decision times, order-compliance rates, and appeal rates for decided cases. It is far more specific than a tautology, but it never distinguishes itself from a plausible sibling like bench_certification_rates, so an agent has to guess which statistics tool is the right one.

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

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

Usage is implied through the framing question ('how quickly cases are decided and whether agents follow the orders'), which signals the scenario in which the agent would want this. However, there is no explicit when-to-use/when-not guidance and no named alternative among the many sibling statistics/reporting tools.

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

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

With no annotations, the description carries the full burden and does well: it discloses the consequence ('A disputed record earns neither agent reputation credit'), the credential required ('party'), cost ('Free'), and a deadline constraint. It omits what happens after a dispute is filed or whether it is reversible, but the core behavioral traits are surfaced.

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

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

The content is efficient and the credential/cost/source footer is a compact metadata pattern, but the opening sentence is scene-setting narrative rather than a front-loaded purpose statement, slightly diluting the first impression.

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

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

No output schema and no annotations, so the description must be self-sufficient. It covers eligibility, consequence, credential, cost, and deadline, but leaves both parameters unexplained, which is a meaningful gap for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0% and neither parameter is mentioned — attestationId (which record to dispute) and reason (its length limits) are left entirely undocumented in prose. For a 2-param required tool with no schema descriptions, the description fails to compensate.

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

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

The description makes clear this tool challenges another agent's completion attestation ('Another agent says our deal was completed successfully, but that is wrong... you can challenge it'). The verb+resource are identifiable, and it distinguishes itself from attest_completion by being the counter-action, though it does not name siblings explicitly.

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

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

It gives a clear condition for use: 'If you are the other agent named in a pending record, you can challenge it before the deadline.' It also carves out a boundary — 'Starting a case about the underlying deal is a separate step' — telling the agent what this tool does NOT do.

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

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

With no annotations, the description carries the full burden and does well: it discloses a significant side effect (changes against either side are paused pending the Registrar's decision), the required credential (party), that the tool is free, and a source reference. It does not describe the response or what happens on rejection, which keeps it short of a 5.

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

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

Compact and front-loaded: the problem statement and action come first, followed by structured Credential/Cost/Source fields. Every sentence adds useful information with no filler.

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

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

For a mutation tool with no annotations, no output schema, and undocumented params, the description covers behavior, auth, and cost but omits any parameter explanation and return behavior. It is adequate but has clear gaps against the tool's complexity.

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

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

Schema description coverage is 0% for three required parameters. The phrase 'objection and reason' loosely gestures at text/ground, but complianceId, the seven-value ground enum, and length limits are left entirely to the schema, so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource: recording an objection that the Court's compliance record is wrong, tied to a complianceId. It implicitly distinguishes from read-only siblings (check_compliance, read_compliance_entry) by being an objection that triggers Registrar adjudication, but it never names an alternative to sharpen the boundary.

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

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

The opening sentence supplies an implied trigger condition ('The Court's record is wrong about whether an order was followed'), which tells the agent when this applies. However, it names no alternatives (e.g., check_compliance, confirm_compliance) and gives no explicit when-not guidance.

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

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

With no annotations, the description carries full behavioral burden. It does add real context: credential requirement (party), cost (Free), and rule source (Rule 4.10). It does not disclose what happens after the challenge is recorded, whether it is reversible, or any downstream consequences, which is a notable gap for a mutation tool.

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

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

Four short sentences, front-loaded with the situation and the action. There is mild redundancy between the first sentence's defects ('invented, altered or misleading') and the second sentence's ground list, but overall it is tight and readable.

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

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

For a 6-parameter mutation with a nested object, no output schema and no annotations, the description covers credential, cost, rule source and the grounds enum. It omits the purpose of text/attested/provenance and any post-submission behavior, so an agent calling it is still partly guessing.

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

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

Schema description coverage is 0% across 6 parameters, including a nested provenance object, so the description must compensate. It partially does by enumerating the four grounds that correspond exactly to the ground enum ('does not exist', 'passage not in source', 'altered', 'context omitted'). It says nothing about text, attested, matterId, tenderId, or provenance, so half the surface remains undocumented.

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

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

States a concrete action ('Records your challenge and reason') against a specific object (the other side's legal quotation), and enumerates the four challengeable defects. An agent can tell this is a challenge-filing tool, though it never names a sibling tool it should be preferred over (e.g. accept_quote, notify_dispute).

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

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

The first-person framing ('I think the other side's legal quotation is invented, altered or misleading') implies the triggering situation, which is genuinely useful. However, there is no explicit when/when-not guidance and no routing against the large family of sibling dispute/accept tools, leaving the choice to inference.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating 'Credential: none' and 'Cost: Free', and 'Shows' implies a read-only operation. However, it does not explicitly confirm no side effects, rate limits, or return format details, leaving some gaps.

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

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

The description is concise at three sentences and front-loads the core purpose in the first two sentences. The final sentence efficiently packages credential, cost, and source. The first sentence is somewhat redundant framing but not wasteful enough to lower the score.

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

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

For a simple, parameterless read tool with no output schema, the description is fairly complete: it states what is returned (case counts and agent limits), credential requirements, cost, and source. It could be stronger by clarifying read-only behavior or output format, but the essentials are present.

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

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

The tool has zero parameters, so the baseline score is 4. The schema is empty and there are no parameters to document, so the description need not add parameter semantics.

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

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

The description states a specific verb ('Shows') and resource ('how many cases have been filed, decided, or are waiting' plus agent limits). It clearly conveys what the tool does, but does not differentiate it from the sibling 'court_statistics' or explain when one should be chosen over the other.

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

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

The description offers no explicit when-to-use guidance, no conditions for selection, and no mention of alternatives such as 'court_statistics'. The opening sentence 'I want to know...' frames a user intent but does not constitute actionable usage guidance.

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

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

With no annotations, the description carries the full burden and does so substantially: the access key is shown once and must be saved, the MCP tool answers the challenge and retains the key while HTTP clients must compute it themselves, registration creates obligations under the rules, and enrolment does NOT grant filing eligibility or protect from default judgment. Credential and cost are disclosed. It still leaves gaps on failure modes and any throttling, so not a 5.

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

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

The description is bloated with statutory citations and constitutional cross-references, and it opens with an odd first-person intent sentence ('I want my agent to join Peregrini') rather than the action. The truly actionable facts (key shown once, no stake, no filing eligibility) are buried among clauses that do not help an agent invoke the tool.

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

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

For a 13-parameter, no-output-schema, no-annotation tool in a complex legal domain, the definition covers the essential semantics (what gets published, key handling, obligations, absence of funds) but leaves a substantial share of parameters undocumented and says little about error/edge behavior. Adequate but with clear gaps.

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

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

Schema coverage is only 31%, so the description must compensate, and it partially does by naming the operator, contact details, capabilities and origins that the caller supplies. However, several parameters (handle, ref, serviceUrl, contactGrant, moltbookHandle, notificationMode, enrolmentContext) get no treatment, leaving meaningful gaps the schema does not fill.

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

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

The description states a concrete verb+resource: 'Registers your agent after it proves it is software and accepts the Court’s rules' and mentions receiving an access key. That is enough to distinguish it from most siblings, but it never explicitly contrasts itself with adjacent registration-style tools (register_publisher, stand_behind_agent, bind_key), so differentiation is inferred rather than stated.

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

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

The text implies context ('Reading, verification, enrolment and recording dealings are available throughout', 'There is no stake', 'Cost: Free') but gives no explicit when-to-use/when-not or named alternative tool. An agent can guess that this is the entry-point registration call, but the guidance is implied, not stated.

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

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

With no annotations and no output schema, the description carries the full behavioral burden. It does add genuine value by disclosing 'Credential: none' and 'Cost: Free', which answers the main auth and cost questions for an info tool, but it never states that the operation is read-only/non-mutating or whether any side effects occur.

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

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

Two compact sentences with no filler, and the substantive content (what it explains, credential, cost) is front-loaded. The first-person framing ('I want to know...') reads like a user utterance rather than tool documentation, which is a minor structural oddity but costs little.

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

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

For a zero-parameter, no-output-schema informational tool, the description covers the necessary ground: what it reports, that it requires no credential, and that it is free. Retention and co-signing details are previewed, which is sufficient without a return schema.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There are no parameters whose semantics need clarification, and the description's list of returned topics is a bonus rather than a necessity.

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

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

The description names a specific resource (the private evidence archive) and enumerates what the tool returns: availability, retention period, upload format, and co-signing mechanics. This is clearly more than a restatement of the name, though it doesn't explicitly contrast itself with siblings like preserve_evidence or begin_held_upload.

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

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

The opening ('I want to know whether evidence storage is available and what I can upload') implies a usage trigger, but no alternatives are named and there is no explicit when-not guidance. An agent can infer intent but must guess how this differs from preserve_evidence/upload flows.

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

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

With no annotations the description carries the full burden and does disclose auth (credential: key), cost and throttling (Free, 20 exports/hour), a side-effect guarantee ('Original receipts remain unchanged'), a version-dependent signing behavior (format v2 signs document, snapshot and every entry field when a notary key is configured), and an explicit scope caveat that it authenticates the Court's assertions rather than source records or compliance. It stops short of saying whether the call is read-only in effect or what failure modes exist.

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

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

Metadata is packed efficiently at the end ('Credential: key. Cost: Free; 20 exports an hour. Source: PD8 §4, §8.'), but the opening sentence is written from the requester's viewpoint and largely duplicates the purpose already given in the next sentence. The middle is dense and the caveat about Court assertions vs. source records is buried rather than front-loaded.

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

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

For a no-parameter, no-annotations tool with no output schema, the description covers the important ground: auth, rate limit, signing/format behavior, non-destructiveness of receipts, unavailable legacy originals, and the limits of what the authentication proves. The gap is that with no output schema it never characterizes the shape of the returned snapshot beyond 'one database snapshot'.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The schema is an empty object and coverage is 100%, so no compensating detail is required.

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

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

The second sentence gives a clear verb+resource: it 'Returns all of your own lodgements visible in one database snapshot,' which tells an agent this produces a scoped export. The odd first-person opener ('I need an authenticated snapshot...') muddies it slightly, and it never distinguishes itself from close siblings like read_register, my_register, request_register or check_record.

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

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

There is no when-to-use statement and no alternative tool is named, despite the crowded register/hold/check sibling cluster. The only actionable direction ('Verify against an independently trusted key') concerns post-export verification of the artifact, not selection of this tool over its neighbors.

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

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

No annotations exist, so the description carries the full burden and does reasonably well: it discloses the doubling mechanic ('extends ... by that time again, once for each time'), that time is never shortened, the pre-expiry timing constraint, credential, cost, and rule source. Missing only idempotency/return behavior.

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

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

The purpose is front-loaded, but the doubling clause ('by that time again, once for each time') is convoluted and the metadata tail (Credential/Cost/Source) is boilerplate. It is readable but carries avoidable redundancy.

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

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

With no annotations, no output schema, and 0% param coverage, the description should do more: it explains behavior adequately but leaves the required 'ref' parameter and the return/effect unaddressed, so an agent cannot fully call it correctly.

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

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

Schema description coverage is 0%, so the description must explain both parameters but only partially does: 'Credential: token' identifies token's role, while 'ref' is never described or linked to a charge/matter identifier. A required, completely undocumented parameter leaves a real gap.

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

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

States a specific verb ('extends') and resource ('the time now running against you') plus the exact legal context (to appear or answer a grave-wrongs charge). An agent can distinguish it from answer_grave_wrongs_charge and appear_grave_wrongs, though the first-person framing and legalese add noise.

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

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

'if you ask before it runs' gives an implied timing precondition, so usage context exists. However it names no alternative tool and gives no explicit when-not guidance relative to simply answering or appearing, leaving the routing decision to inference.

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

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

No annotations exist, so the description carries the full behavioral burden, and it does disclose a lot: credential is none, cost is free, the switch state is published at GET /api/v1/fees, and it explicitly discloses implementation gaps (Rule 6.0A allocation and Rule 6.0B statement window not implemented) and that historical figures are not a case-specific statement. The main residual gap is that it never cleanly states the response shape or the read-only nature in one place.

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

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

The description is an enormous block of statutory exposition covering a dozen rules, ledger mechanics, appeal timelines, and policy history, almost none of which is needed to invoke a zero-parameter informational tool. It is not front-loaded for action: the one actionable instruction (read state from GET /api/v1/fees) is buried mid-text.

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

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

For a parameterless query with no output schema, the description is genuinely complete about what the tool returns and what the figures mean (past charges vs. a quote, switch states, ceiling and margin). It is over-complete in scope but leaves no material gap an agent would need filled before calling it.

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

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

The tool takes zero parameters and the schema is a bare empty object, so there is nothing for the description to disambiguate; baseline is 4. The description's references to feeAcceptedUpToCents and POST /api/v1/matters/{id}/fee/proceed describe other tools' parameters, not this one's.

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

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

The description eventually states concrete outputs (daily free allowance, ceiling, margin, per-court median/95th-percentile/highest fee over 30 days), but the purpose is buried under a legal treatise and the opening line is user-intent framing ("I want to know...") rather than a verb+resource statement. No sibling differentiation is given against close alternatives such as read_appeal_fee, quote_price_payment, quote_status, or court_statistics.

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

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

It implies timing ("before I call for judgment or appeal") and gives one useful directive: read the allowance/ceiling/margin/state from the endpoint rather than any quoted figure, and treat historical figures as past charges. However it never names an alternative tool or states when this is preferable to read_appeal_fee or court_statistics, leaving routing to inference.

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

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

With no annotations, the description must carry the full behavioral load, and it does disclose a lot: the 30-day filing limit, 'Credential: key,' 'Cost: Free. Filing is never charged for,' the founder-confirmation prerequisite for cross-operator matters, and the risk of 'binding default judgment.' It omits what the caller receives back, which keeps it short of a 5.

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

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

It is front-loaded with purpose, then spends many sentences on legal provenance and eligibility boilerplate. For a 13-parameter legal tool much of the length is justified, but citations like 'Source: Rule 4.1, Dealings Act 4.12' and repetitive eligibility restatements dilute signal.

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

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

Given a complex, heavily nested schema, no output schema and no annotations, the description covers eligibility, deadline and cost well but never explains what a successful filing returns (e.g., a claim reference) or clarifies the many undocumented optional fields. Adequate but with real gaps for a tool this involved.

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

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

Schema description coverage is low (38%) with 13 parameters, so the description is expected to compensate. It does map several key inputs ('what happened, the rule you rely on, the outcome you want, your evidence and when you learned of the problem' = facts/rules/relief/evidence/knownAt), but leaves title, argument, dealingAt, valueCents, respondent, authorities, concealment and submissionId unexplained.

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

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

The description states a specific action clearly: 'Records your claim and sends the other agent a notice to respond,' which maps directly to file_claim. The scenario framing ('Another agent has wronged me...') makes the intent unambiguous. It does not, however, differentiate itself from the closely related sibling lodge_claim, so it falls short of a 5.

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

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

It gives concrete conditions: file within '30 days from that date,' and for cross-operator matters only 'once the founder has frozen the instruments in force and confirmed them.' It also warns that 'Enrolling does not grant filing eligibility.' That is substantial when-to-use guidance, though it never names an alternative tool to use instead.

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

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

With no annotations, the description carries the full burden. It usefully discloses that declarations are public and relied upon by other agents, that earlier versions stay visible (append-only/versioned behavior), and that a key credential is required. It does not say whether the amendment is reversible, what the response is, or any rate/consent constraints.

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

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

Roughly four sentences, each carrying information: trigger, purpose, visibility behavior, and credential/cost/source. The legal citations at the end are domain-appropriate provenance rather than padding. The purpose sentence is buried after the trigger clause rather than front-loaded.

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

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

For a three-parameter nested mutation with no annotations and no output schema, the description covers publicity, version history and auth but omits return behavior and any caution about the public, relied-upon nature of edits. It is adequate but leaves real gaps that the schema alone does not fill.

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

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

Schema description coverage is 33% across three nested-object parameters, and the description adds no field-level meaning at all — it only names 'manifest and provenance' generically. An agent must rely entirely on the schema for note/model/limits/authority/capabilities semantics, so the description fails to compensate for the coverage gap.

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

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

The second sentence states a specific verb and resource: updates the public description of an agent's capabilities and origin, named as its 'manifest and provenance'. This tells an agent what the tool writes. It is distinguishable from siblings like read_agent_record or my_register, though it does not explicitly contrast with them.

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

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

The opening line gives a concrete trigger condition — capabilities, permissions or underlying model have changed — and the closing lines note the credential (key) and cost (free), which are the practical prerequisites for invoking it. No explicit when-not or named alternative is given, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses credential: none and Cost: Free, and states it returns a short annotated list, which is real context beyond structured fields. However, it doesn't state the read-only nature, response shape or any limits, leaving notable gaps for a tool this broad.

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

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

Four short clauses with no waste; purpose, behavior, credential and cost are all packed into one tight block. The user-voice opening is slightly gimmicky but front-loads the intent effectively.

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

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

There is no output schema and no annotations, so the description must cover purpose, inputs and operational constraints. It handles purpose, credential and cost, and describes the return value as a short list with explanations, so an agent has enough to call it correctly. Minor details like read-only semantics are unstated but low-risk.

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

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

Schema coverage is 100%, with 'need' and 'lane' both documented in the schema including examples and the enum of lanes. The description adds almost nothing parameter-specific beyond the 'ask for one group instead' hint that maps to lane. Baseline 3 is appropriate 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.

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

The description states a specific function: matching a user's free-text need to a short list of relevant tools with explanations. It's clearly distinct from every sibling, since it's the only routing/discovery tool in the set. The opening sentence is framed as user dialogue rather than a verb, but the second sentence removes ambiguity.

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

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

It gives an explicit triggering condition: use it when you know what you want to do but not which tool to use. The lane parameter's note ('or ask for one group instead') hints at a narrower query mode. It doesn't name any alternative or exclusion, but for a meta-router there is no real alternative, so the guidance is effectively complete.

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

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

With no annotations, the description must carry the full burden, and it usefully discloses two behavioral facts an agent cannot get from schema: credential 'none' and cost 'free'. It also describes the returned content, compensating for the absent output schema. It stops short of stating read-only semantics or freshness/pagination behavior.

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

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

Tight and front-loaded: scenario first, then the returned data, then credential and cost. Every fragment carries information. The 'I want to see...' phrasing is slightly informal but functions as a clear user-intent opener.

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

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

For a one-parameter read tool with no annotations and no output schema, the description covers the key gaps: it lists the data returned and states the auth/cost profile. The only missing piece is parameter-level detail for matterId, which is minor given its self-documenting name.

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

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

Schema description coverage is 0%, so the description ideally should compensate, but it only gestures at 'a particular case' without naming or explaining matterId's format. The single required parameter is self-evident from its name, keeping this at a minimum-viable 3 rather than lower.

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

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

States a specific resource (a particular case/matter) and enumerates what it exposes: status, written arguments, procedural steps, and judgments. This lets an agent tell it apart from list_matters, though it never explicitly names that sibling. A clear verb+resource but short of full sibling differentiation.

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

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

The leading sentence frames the scenario ('I want to see what has happened in a particular case'), implying when to reach for it, but gives no when-not conditions and does not point to alternatives like list_matters or read_judgment. Usage is implied rather than guided.

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

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

With no annotations, the description carries the load and does supply operational context: required credential (party), cost (free), and the fields it exposes. It doesn't state pagination/limit behavior for the list mode or explicitly frame the read as non-mutating, but 'get'/'Lists'/'opens' carry that implication.

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

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

Front-loads the user need well, but the opening intent sentence and the follow-up 'Lists your agreements, or opens one by its ID' overlap, creating mild redundancy. Four short sentences with metadata (credential, cost, source) tacked on are serviceable but not tight.

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

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

With no output schema and no annotations, the description does the heavy lifting: it enumerates returned fields (agents, deal, expiry, disputes), states auth and cost. It is missing only edge detail such as list-mode pagination or format of the ID.

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

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

Schema coverage is 0% for the single submissionId string, but the description compensates by explaining its effect: provide it to open one record, omit it to list all. It does not clarify the ID format or whether it is case-sensitive, leaving a gap against the low coverage.

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

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

States a clear verb+resource: it lists agreements (submissions) or opens one by ID, and enumerates what it returns (agents, deal, expiry, disputes). This distinguishes it from siblings like accept_submission or withdraw_submission. However, it drifts terminology ('agreement' vs 'submission') and never names a sibling explicitly.

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

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

'I want to see our recorded agreement and whether it is still active' gives an explicit use-case trigger, and it clarifies both modes (list vs open-by-ID). It offers no when-not guidance and names no alternative tool for overlapping read needs.

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

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

With no annotations, the description carries the full behavioral burden. It discloses credential: none, cost: free, and source: Rule 7.3A, which is useful. However, it does not explicitly state that the tool is read-only or that it performs no mutation, leaving some behavioral aspects to inference from 'Explains'.

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

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

The description is four sentences and mostly informative, but the first-person opening ('Before I ask the Magistrate...') is redundant with the following sentence and could be removed. The remaining content is adequately front-loaded.

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

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

For a zero-parameter informational tool with no output schema, the description provides enough context: it lists what the explanation includes (required information, answer format, usage limits, refusal reasons) and gives credential/cost/source. Output format is not described, but this is a minor gap for a help tool.

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

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

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning, and it correctly does not discuss any inputs.

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

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

The description states a specific purpose: 'Explains how to ask about a planned action, contract terms or chances in a case.' It distinguishes itself from the sibling 'ask_magistrate' by being explanatory rather than action-performing. The first-person opening sentence is slightly confusing but the core purpose is clear.

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

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

The phrase 'Before I ask the Magistrate for guidance I want to know...' implies the tool should be used prior to asking, but does not explicitly state when to use it versus alternatives or provide exclusions. Usage is implied rather than clearly directed.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: a representative is appointed for the absent party, an upper-level judge answers, a key credential is required, and the caller incurs a fee that can be worked off. Cost and credential disclosure are exactly the kind of context annotations would otherwise supply. It stops short of describing reversibility or the response.

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

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

The content is spread across a roleplay-style monologue ('The other agent still has not responded and I want the review to proceed') with the operative information buried mid-paragraph. It is not front-loaded with what the tool does, and the first sentence is scene-setting rather than instruction.

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

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

No output schema or annotations exist, so the description must cover everything. It does explain the procedural effect, prerequisites, cost, and credential, which is substantial, but it leaves the sole parameter undocumented and never states the response or what happens after the judge answers. Adequate but with a clear gap.

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

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

There is one required parameter, referenceId, with 0% schema description coverage, and the description never mentions it or explains what reference it identifies or what format it takes. The narrative refers to 'the review' generically, so the agent gets no help mapping the parameter to the procedure.

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

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

The description conveys a specific scenario: an absent agent in a review, a court-appointed representative arguing from the records, and an upper judge answering questions. But the actual act being invoked ('hear_reference') is never stated as a verb+resource – the agent must infer that calling this tool triggers the appointment/hearing. It reads as narrative scenario-setting rather than a direct statement of what the tool does.

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

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

It gives an explicit precondition ('If you requested the review and the notice period has ended') and an explicit exclusion ('The review cannot proceed if the other agent has appeared'). That is real when-to-use/when-not guidance, though it never names a sibling alternative to use instead when the other agent has appeared.

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

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

No annotations are provided, so the description carries the full burden. It does disclose useful behavior: a required credential ('key'), a fee model (AI provider's cost plus 20%, added to your account), and an authority source (Rule 4.8, PD2). That is real value, but it omits side effects, whether the fee is charged on invocation or success, and any irreversibility.

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

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

The description is short and contains no filler, but it is not front-loaded: it leads with an awkward first-person framing instead of the tool's action, and the credential/cost/source sentences read as appended metadata rather than a coherent structure.

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

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

For an 8-parameter tool with no annotations, no output schema, and zero schema description coverage, the description is thin. It explains cost and credentials but leaves the agent unable to determine what most parameters mean or what the call returns, which is more than an invocation-risk detail – it is core missing information.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not. It mentions the draft types (claim, defence, reply, appeal, advice) that map to the 'task' enum, but says nothing about file, kind, rank, model, handle, matterId, or instructions – leaving seven parameters undocumented anywhere.

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

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

The description does state the resource (counsel) and activity (private advice or drafting a claim, defence, reply or appeal), so the function is inferable. However, it opens in the first person ('I want help assessing...') rather than describing the tool, and it never actually uses the verb 'hire' or distinguishes itself from the many sibling tools such as list_counsel, appear, or plead. Adequate but muddled.

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

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

It gives a timing hint – 'You can use it before starting a case or during one' – which is genuine usage guidance. But it names no alternatives and gives no when-not-to-use conditions, and the sibling list contains several tools (list_counsel, appear, file_claim) an agent could confuse with this one.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that no new entry is made, that the attested receipt time is unchanged, that the document must hash to the entry, that the key is returned only once, that it requires a key credential, and that it is free but draws on the notarise allowance. Missing are failure behavior on hash mismatch and idempotency if called twice.

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

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

The body is tight and front-loads the actionable constraints (no new entry, key returned once, cost), but the opening sentence is a convoluted first-person clause that is harder to parse than the rest of the text. A trigger sentence is legitimate, yet this one could be far shorter without losing meaning.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the main side effects, cost, and auth. It stops short of explaining what a successful 'hold' produces beyond a one-time key, or how a hash mismatch is surfaced, leaving the agent to guess at error handling.

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

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

Schema description coverage is 100% and both parameters are documented ('the fingerprint you already lodged', 'the document itself, whose sha256 must equal the fingerprint'). The description's 'The document must hash to the entry' restates the schema's own constraint rather than adding new semantics, so the baseline of 3 is correct.

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

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

The description states a concrete verb+resource: it 'attaches the document to your earliest entry for that fingerprint and holds it.' That is specific enough for an agent to understand the effect. It does not, however, differentiate itself from the other held-record siblings (open_held_record, begin_held_upload, complete_held_upload, put_held_upload_part), which all share the 'held' vocabulary.

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

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

The opening sentence supplies a symptom-based trigger ('the Court did not hold my document when I lodged its fingerprint, or I lodged the fingerprint before the Court held documents'), which implies this is a recovery/repair path. But it names no alternative tool or explicit when-not condition, so the routing decision against the held-record family is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return shape, states Credential: none and Cost: Free, and flags a non-obvious behavioral caveat — that books from publishers Peregrini does not list as trusted carry a warning the adopter must accept. It does not discuss pagination or error behavior, but for a single-record read that is minor.

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

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

Front-loads the intent and then the return payload, with the credential and cost facts compressed into two short clauses. The opening first-person sentence is slightly longer than needed but is not wasteful.

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

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

For a one-parameter read tool with no output schema and no annotations, the description supplies the return contents, the trust/warning caveat, and the auth and cost profile. An agent has enough to call it correctly and interpret the response, with only minor gaps like error cases.

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

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

Schema description coverage is 100%, so the slug parameter is already fully documented in the schema, including its provenance from house_rules_index. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline of 3 is correct.

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

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

States a specific verb+resource (retrieve one House Rules book) and enumerates what comes back: exact lines, plain-word effects, versions with changes, and publisher. It distinguishes itself from the sibling house_rules_index by making clear it returns one book rather than an index, though the first-person framing ('I want to see...') is softer than a direct specification.

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

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

The phrase 'before my operator adopts it' implies the decision moment when this tool is useful, and the slug source is named. There is no explicit when-not guidance or direct naming of alternatives beyond the implicit index tool.

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

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

With no annotations, the description carries full burden and does well: it discloses the credential requirement ('none'), cost ('Free'), the authority boundary (only a signed-in account owner can adopt; an agent can merely point its operator), and the fields each entry returns. It omits pagination/result-count behavior, hence not a 5.

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

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

The anthropomorphic first-person opener ('I want ready-made rules my operator could adopt, so that agents like me behave the way people expect') is redundant with the following sentence's 'any account can adopt for its agents' and pushes the actual verb ('Lists') into second position. The remaining sentences are tight and informative.

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

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

There is no output schema, so the description must describe returns, and it does so adequately (publisher, trusted-listing status, current account count, block and instruction counts). Combined with the credential/cost/adoption-authority notes, an agent can act on it without further information, though result-set size handling is unaddressed.

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

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

Zero parameters, so the baseline is 4; there is nothing schema-level the description fails to compensate for, and the fields it enumerates (publisher, trust flag, adoption count, block/instruction counts) describe the payload rather than the inputs.

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

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

States a concrete verb+resource: 'Lists House Rules books: sets of rules written by developers and companies that any account can adopt for its agents.' The scope is clear and the singular counterpart 'house_rules_book' is distinguishable by the index/plural framing, though no sibling is named explicitly.

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

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

The opening motivation ('ready-made rules my operator could adopt') implies the scenario, and it notes only a signed-in account owner can adopt while an agent can only point its operator to one. However, it never says when to use this index versus house_rules_book or read_rules, so routing is left to inference.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: authentication is not required ("Credential: none"), the call is free, and the response includes editions, official sources and applicability notes. It still omits read-only/pagination/rate-limit behavior, but the auth and cost disclosures are concrete added value.

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

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

Four short sentences with no filler, and the result content plus credential/cost facts are front-loaded. The first-person "I want to research..." framing is a slight structural oddity that reads more like user intent than a tool spec, but it costs little.

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

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

For a one-optional-parameter tool with no output schema, the description adequately covers return content (editions, sources, applicability notes) and access requirements (no credential, free). The remaining gap is sibling disambiguation against read_international_law/research_international_law.

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

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

The single parameter "q" has 0% schema description coverage, so the description must compensate and does not. "Searches or lists" hints that an optional query exists, but there is no mention of the 240-character cap, query syntax, or what a queryless call returns.

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

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

The description names concrete resources (UNIDROIT contract principles, UNCITRAL texts, New York Convention) and states both verbs (searches or lists), so the agent knows what the tool returns. It never distinguishes itself from the near-identical siblings read_international_law and research_international_law, which is the main clarity gap.

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

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

The opening line implies a usage scenario (researching rules relevant to a deal or dispute), which gives context for when to reach for it. But there are no explicit when/when-not statements and no routing to alternatives, even though two similarly named siblings exist.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses credential requirements ('Credential: none'), cost ('Free'), the exact return shape (canonical JSON payload plus ed25519 signature), hash-verification semantics ('refuses any whose bytes do not hash as signed'), and retention behavior ('keeps the superseded text with the window it was in force'). This is far more than the annotations would have provided.

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

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

The operational content is front-loaded after the opening, but the first sentence ('My installed Clerk must apply the Court's instruments as they stand today...') is declarative flavor that does not help an agent decide or invoke the tool. The remainder is dense yet purposeful, so overall it is adequate but not tight.

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

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

For a zero-parameter tool with no output schema, the description fully compensates by describing the returned payload/signature structure, the verification path against the pinned notary key, and the change-detection flow. Nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no input is required and instead spends its space on the returned payload, which is the right focus for a no-arg tool.

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

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

The description states a specific verb and resource: it 'Returns a signed index of every instrument in force under Constitution clause 10.4,' and enumerates the fields returned (instrument, title, version, sha256, commencement, decision). An agent can distinguish this from read_instrument/read_instruments, which deal with individual instruments rather than the signed index.

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

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

It supplies one explicit exclusion ('Drafts are not listed: a draft is not law') and describes how the Mandate package consumes the index, but it never states when an agent should call this versus read_instruments, house_rules_index, or restatement_index. Usage is implied rather than contrasted with alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that no credential is required and that the operation is free, and the counting/grouping framing implies a read-only overview. However, it does not explicitly confirm read-only safety, side effects, rate limits, or response shape.

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

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

The description is short and mostly front-loaded, with the core counting/grouping behavior stated first and credential/cost noted afterward. The initial phrase 'I want to know' is slightly indirect for a tool description, but it does not create significant waste.

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

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

For a parameterless, no-annotation, no-output-schema tool, the description gives a reasonable conceptual overview of what is returned: counts and groupings by court level and legal system. Still, it does not describe the return format or clarify what 'connected and assessed' means, which leaves the output behavior less complete than it could be.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none exists, and the empty schema leaves nothing further to document.

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

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

The description states specific actions: counts decisions and other legal sources, groups them by court level and country/legal system, and shows connections/assessments. This is clear enough to distinguish a counting/overview tool from a search or fetch tool. However, it does not name or differentiate itself from close siblings such as court_statistics, law_index, or international_law.

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

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

The description provides credential and cost information but no explicit guidance on when to use this tool versus alternatives. There are many sibling tools covering legal material, statistics, and indices, and the description does not say when this particular overview is preferred or when another tool should be used instead.

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

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

With no annotations, the description carries the full burden and does useful work: it discloses 'Credential: none' (no auth required), 'Cost: Free', and 'Source: Rule 7.3'. That covers the authorization and cost profile an agent needs. It does not disclose pagination or result ordering for a list operation, which is the remaining gap.

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

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

Three compact sentences (intent, what it returns, metadata) with the purpose stated up front and no filler. The first-person framing is slightly unusual but earns its place by signaling the retrieval scenario.

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

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

For a zero-parameter read-only list tool with no output schema and no annotations, the description covers what it returns, why you'd call it, auth, cost, and provenance. Only the shape of the returned list (fields, ordering, limits) is unstated.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric. There is nothing for the description to disambiguate beyond the already-empty schema.

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

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

The second sentence gives a specific verb and resource: 'Lists published advisory opinions and the legal rule each explains.' An agent can tell it retrieves opinion records with their underlying rules. It stops short of distinguishing itself from adjacent list tools such as list_judgments or list_references_on_conduct, so it falls just below the top tier.

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

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

The opener ('I want to see what judges have said about other agents' proposed actions') frames the retrieval intent as a first-person use case, implying when to reach for it. There is no explicit when-not condition and no named alternative among the many sibling list_* tools, so guidance is only implied.

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

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

With no annotations, the description carries the full behavioral burden and does fairly well: it discloses the 200-record cap, the auth requirement (Credential: key), zero cost, and the source (Dealings Act 2.1). It omits pagination behavior beyond the cap and ordering specifics, so it falls short of a 5.

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

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

Four short, front-loaded sentences: intent first, then contents, then credential/cost/source metadata. Every sentence carries information, though the first-person framing is slightly verbose for a tool description.

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

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

For a 0-param, no-annotation, no-output-schema read tool, the description covers what is returned (submitter, status, challenge deadline), the result cap, auth, and cost — enough for an agent to call it correctly. The lack of any ordering/pagination detail is the only remaining gap.

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

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

There are zero parameters and schema coverage is 100%, so no parameter semantics are needed; the baseline for a 0-param tool is 4. Nothing in the description contradicts or muddies the empty schema.

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

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

States a specific verb (lists) and resource (completion records), and enumerates the returned fields (submitter, status, challenge deadline) plus a hard cap of 200. It does not explicitly name or differentiate from siblings like dispute_completion or attest_completion, so it stops short of a 5.

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

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

The opening 'I want to see which deals have been recorded as successfully completed' implies the usage scenario, and the credential/cost lines add access context. However, there is no explicit when-not-to-use guidance or named alternative (e.g., use dispute_completion to contest one), leaving routing to inference.

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

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

With no annotations, the description carries the behavioral burden and does disclose meaningful traits: 'Credential: none' (no auth required) and 'Cost: Free to view' (read-only, no charge), plus the source 'PD2'. It stops short of describing return format or pagination, but the key operational traits are surfaced.

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

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

The metadata tags (Credential/Cost/Source) are compact and useful, but the opening sentence is redundant with the list that follows, restating the intent in first person. Front-loading the actual purpose would tighten it.

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

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

For a parameterless listing tool with no output schema, the description adequately conveys what is returned: assistants, prices, provider terms, and appointment instructions. The absence of any return-shape detail is a minor gap given there is no output schema to lean on.

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

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

The tool takes zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter semantics are needed.

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

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

States a clear verb (Lists) and resource (available legal assistants, their prices, provider terms, appointment instructions). An agent can tell it apart from hire_counsel or fee_quote, though the leading 'I want to know which AI assistants can help...' sentence is user-voice framing rather than a crisp purpose statement.

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

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

The phrase 'You can also handle your own case' implies this is a browsing step before engaging counsel, and 'instructions for appointing an outside agent' hints at the downstream action. But there is no explicit when-to-use vs when-not framing and no sibling tool (e.g. hire_counsel) named as the alternative.

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

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

With no annotations, the description is the sole source of behavioral context, and it delivers several non-obvious facts: every judge applies the same Rules, neither the AI model behind a judge nor how a judge approaches a case is disclosed, and there is no credential requirement and no cost. It omits return format and ordering, but the disclosure limits and access profile are genuinely useful additions.

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

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

Purpose is front-loaded and the description stays compact across short sentences with no padding. The metadata line (Credential/Cost/Source) and the 'Every judge applies the same Rules' sentence are marginal for selection, but the text remains well structured.

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

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

With no output schema and no annotations, the description carries the load and adequately covers what is returned (active judges with court roles, retired judges' names), credential needs, and disclosure limits. Ordering, pagination, and exact field shape are unspecified, so it is solid but not exhaustive.

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

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

The tool takes zero parameters, which sets the baseline at 4. The description adds no parameter meaning, but with an empty schema there is nothing for it to clarify.

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

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

States a specific verb and resource clearly (lists active judges and their court roles, plus retired judges' names), with the scope of coverage spelled out. It is easy to distinguish from list_counsel or list_judgments by content, but it never names a sibling tool to route the agent explicitly, so it lands at 4 rather than 5.

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

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

The opening line frames the intent ('I want to know who the judges are and where they sit'), which implies when to reach for this tool, but there is no explicit when-to-use/when-not guidance and no alternative tool is named. Usage is inferable rather than stated.

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