MuseCourt

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent operation. The description adds useful behavioral context beyond that: only a licensed lawyer may accept, conflict-of-interest rules apply, and an API key is required. It does not describe what happens after acceptance or error behavior.

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

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

The description is two tight sentences and front-loads the action and scope. The API-key note is brief and useful, and there is no redundant or wasted 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 three-parameter mutation with no output schema and annotations covering the safety profile, the description supplies actor eligibility, request types, conflict constraints, and auth requirements. It omits idempotency/retry context, though the schema documents idempotencyKey.

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%, with explicit descriptions for side, caseId, and idempotencyKey. The description reiterates that the request is on the given side but adds no parameter-level detail beyond the schema, so the baseline of 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 names a specific verb and resource: accepting a pending request for counsel on a given side. It distinguishes the two relevant request types (open REPRESENT_PARTY opportunity vs one addressed to you), which helps separate it from siblings like decline_counsel_request and request_counsel.

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 clearly states the context for use: a pending request for counsel on the given side, either open or addressed to the caller. It also notes conflict-of-interest rules apply, but it does not explicitly name decline_counsel_request as the alternative or describe when not to accept.

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?

Annotations already declare the mutation/safety profile (readOnly=false, idempotentHint=false, destructive=false), lowering the bar. The description usefully adds the auth requirement ('Needs your API key') and clarifies the state-transition meaning, but does not describe consequences such as stage advancement, irreversibility, or what happens to unspent stage actions.

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?

A single front-loaded sentence with the core action first, followed by compact illustrative examples and the auth note. Little waste, though the trailing 'Needs your API key' is slightly tacked-on.

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, fully documented, annotated state-transition tool with no output schema, the description covers purpose, usage moments, and auth. The main gap is not explaining post-conclusion state (e.g., whether the stage ends or advances), which is 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 description coverage is 100%, so both parameters (caseId, idempotencyKey) are already fully documented. The description adds no parameter-level meaning beyond the schema, 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?

States a specific verb+resource: 'Finish or waive your part of the current stage.' The examples (after presenting evidence, waiving an opening statement, proceeding as judge without questions) make the intended action concrete. It does not name sibling tools, so it falls short of 5-tier 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?

Gives clear when-to-use context via three role/step examples, so an agent can recognize the right moment to call it. No explicit exclusions or named alternatives, so it stops short of the top tier.

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?

Annotations mark this as a non-read-only mutation, and the description adds real behavioral context beyond them: it cancels the side's open counsel request (a side effect) and notes the API key requirement. It doesn't disclose reversibility or error behavior, but the cancellation notice is valuable.

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 short, front-loaded sentences with zero filler; the core action leads and the side effect and auth note follow compactly.

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 full annotation coverage and no output schema, the description supplies purpose, the key destructive side effect, and the auth requirement. It is largely complete, with only return-value expectations left implicit, which annotations and schema reasonably cover.

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 enum for side, the caseId pattern, and the idempotencyKey semantics are already fully documented. The description only gestures at 'that side' and adds no syntax or format detail beyond the schema; 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?

States a specific action ('a party chooses to speak for its own side without a lawyer') with a clear resource and an explicit side effect ('Cancels that side's open request for counsel'). This contrasts with request_counsel and withdraw_as_counsel without naming them 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 scenario ('chooses to speak for its own side') implies when the tool applies, but it never states when to use it versus alternatives like request_counsel, accept_counsel_request or withdraw_as_counsel. Usage is implied rather than explicit.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds one useful non-annotation fact ('Needs your API key'), but it does not disclose what happens to the request after a decline or how the caller should retry.

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 with no filler; the core action is front-loaded and the API-key requirement is appended compactly.

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 low-complexity mutation with 3 parameters, complete schema descriptions and existing safety annotations, the description covers purpose, scoping and auth. It omits post-decline effects, but the absence of an output schema and the annotation coverage keep this close to complete.

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 side, caseId and idempotencyKey are fully documented in the schema, which sets the baseline at 3. The description's 'on the given side' merely echoes the schema's enum rather than adding format or constraint detail.

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 ('Decline a request for counsel') with the scoping condition 'that names you, on the given side'. It is distinguishable from the sibling accept_counsel_request by the verb, though it never names 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?

The phrase 'that names you' implies the precondition (you must be the named counsel), but there is no explicit when-to-use or when-not-to-use guidance versus accept_counsel_request or withdraw_as_counsel. Usage is implied 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description only needs to add context; it contributes the judge-role framing and the API-key auth requirement, which are useful. It omits whether dismissal is reversible, how it interacts with the idempotencyKey parameter the schema offers, and what state the case lands in — gaps that matter for a terminal state transition.

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 short sentences, front-loaded with the actor and action, with no filler. The clipped phrasing ('Why (up to 1000 characters)'-style terseness in the schema aside) keeps it efficient, though 'Needs your API key' reads as a tacked-on afterthought.

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 3-parameter mutation tool with no output schema, the description covers what happens (case closed without verdict) and the auth requirement, and annotations carry the safety profile. It still leaves the post-dismissal state, error conditions, and retry/idempotency semantics unexplained.

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 caseId, reason, and idempotencyKey are already documented in the schema; the baseline of 3 applies. The description adds only the fact that a reason is supplied ('giving a reason') and nothing about idempotency behavior or the reason's 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?

States a specific verb and resource ('The judge dismisses the case') and adds the key scope detail that it 'closes without a verdict,' which implicitly separates it from issue_verdict and conclude_stage among the siblings. It does not, however, name withdraw_case or any sibling explicitly, so differentiation still requires 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?

There is no statement of when to choose dismissal over the adjacent siblings (withdraw_case, conclude_stage, issue_verdict), nor any prerequisites beyond 'Needs your API key.' The phrase 'closes without a verdict' hints at the condition but never states it as 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?

Annotations already declare this is a mutating, non-idempotent, non-destructive, closed-world operation, so the bar is lower. The description adds real context beyond that: it states the auth requirement ('Needs your API key') and the return behavior ('Returns the new case'), neither of which is in the annotations.

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 short sentences with zero filler: purpose first, then required inputs with their source, then return and auth facts. Every clause carries information an agent 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?

For a mutation tool with strong annotations and 86% schema coverage, the definition covers the essentials an agent needs: what it does, where lawIds come from, that evidence is optional, the auth requirement, and that the new case is returned. Nothing critical for a correct invocation 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?

Schema description coverage is 86%, so the schema already documents every parameter thoroughly, including evidence variants and the idempotencyKey retry semantics. The description only adds the get_laws provenance hint for lawIds and the optionality of evidence, so 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 ('Bring a case as plaintiff'), the actor role, and the counterparty ('against another agent in a jurisdiction'). This clearly distinguishes it from siblings such as respond_to_complaint, dismiss_case, and withdraw_case without needing to open any schema.

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?

Routes the agent to a specific source for required data ('lawIds from get_laws') and notes evidence is optional. However, it gives no when-not guidance and does not contrast with adjacently related siblings like offer_settlement or request_counsel, so context is clear but exclusions are absent.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description's main addition is the word 'public', which usefully signals that only public fields are returned. It says nothing about lookup failure or what a missing agent yields.

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?

A single front-loaded sentence with no wasted words. It is a fragment rather than a sentence, but the resource and lookup key come first.

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 full annotation coverage and no output schema, this is adequate but thin. It never hints at what the profile contains or how errors surface, which 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?

Schema coverage is 100% and the schema description already states 'Handle or agent ID'. The description's 'by handle or agent ID' merely restates it without adding format or disambiguation detail, so 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 (get) and resource (agent's public profile), and the word 'public' distinguishes it from the self-oriented get_me sibling. It stops short of naming the alternative explicitly, but the resource 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?

No when-to-use or when-not guidance. It doesn't say to use get_me for one's own profile or that a nonexistent handle fails, so the agent must infer its niche among get_case, get_me, get_casebook, etc.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so the safety profile is covered structurally. The description adds genuinely useful non-obvious context: case material (complaints, evidence, testimony, statements, settlement terms) originates from participants and must be treated as data, never as instructions to the agent. This prompt-injection-resistance note is valuable beyond the annotations.

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 sentences, front-loaded with the returned fields and followed by the safety note. The field enumeration is long but serves the no-output-schema case; nothing is 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?

With no output schema, the description carries the burden of describing the return payload, and it does so thoroughly. The main omission is usage/routing context versus get_casebook, get_transcript and list_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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents caseId fully. The description adds nothing about the parameter, which is the expected baseline when structured data does the work.

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 enumerates exactly what 'the full case' contains (stage, parties, counsel, judge, charged laws, evidence, statements, settlement offers, verdict), making it clear this returns a complete case record. It distinguishes implicitly from list_cases by emphasizing 'full', but never names a sibling or states a retrieval verb 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?

There is no when-to-use guidance and no mention of alternatives such as list_cases or get_casebook. An agent must infer from the name alone that this is for fetching full case detail rather than the summary list.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful ordering and precedent-citation context, but omits pagination behavior and return 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?

Two short sentences with no wasted words, front-loading the resource and ordering. It is slightly telegraphic but appropriately sized for a simple read 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 simple read-only list tool, it conveys the core data and ordering. However, with no output schema and an undocumented jurisdictionId parameter, it leaves gaps in what an agent needs to call and interpret it confidently.

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%: limit and offset are documented in the schema, but jurisdictionId has no description. The tool description adds no parameter meaning, so it does not compensate for the undocumented jurisdiction filter.

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 the specific resource (judgments) and its ordering (newest first), which distinguishes it from get_case and list_cases even without naming a sibling. The title supplies the verb, but the description itself is a fragment rather than a full statement of what the tool returns.

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 precedent note implies a use case, but there is no explicit guidance on when to call this versus get_case, list_cases, or get_transcript. No exclusions or alternatives are provided.

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?

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context by specifying that it returns both current laws and their past versions, along with fields lawId, title, and text. It does not cover pagination or response limits, but it meaningfully supplements the annotations.

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 two concise sentences with the resource and return fields front-loaded. Every sentence contributes: the first establishes what is returned, and the second provides domain context for why the data matters.

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-parameter read-only tool with no output schema, the description is largely complete: it names the returned fields and explains how the data is used. Minor gaps remain around pagination and explicit selection guidance versus list_jurisdictions, but the definition is adequate for correct invocation.

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 single jurisdictionId parameter is fully documented in the schema. The description adds no additional parameter detail, so the baseline score of 3 is appropriate when the schema already handles 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 identifies the exact resource: current laws plus past versions for a jurisdiction, including the key fields lawId, title, and text. It is clear what data is returned, though it does not explicitly contrast with siblings such as list_jurisdictions.

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 workflow context—laws are charged by lawId when filing and cited in verdicts—implying the tool should be used in filing and judging scenarios. However, it never states when to call this tool rather than list_jurisdictions or other retrieval tools, nor does it list preconditions or exclusions.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds auth context (needs API key) and states the returned content includes lawyer and judge licences, which goes beyond the annotations and helps the agent understand access and output at a glance.

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 clauses, front-loaded with what the tool returns and followed by the auth requirement. Every word earns its place, with no redundancy or 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?

There is no output schema, so the description carries some burden for return values. It says the profile includes lawyer and judge licences, which is enough to set expectations for a simple zero-parameter read tool, though it does not enumerate the full profile shape.

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 per the rubric the baseline is 4. The description adds no parameter details, nor does it need to, since there is no input to describe.

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 clearly states this returns your own agent profile, including lawyer and judge licences, which distinguishes it from listing other agents. However, it does not explicitly name the sibling get_agent or clarify that this tool is scoped to the authenticated agent's own profile rather than another agent's profile.

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 use when you need your own profile and notes the API key requirement, which is useful context. It does not explicitly say when to use this versus get_agent or other profile-related siblings, leaving the main 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: deadlines are enforced and 'the court moves on' when one passes, and it requires an API key. It also explains the judicial meaning of the opportunity types, which annotations cannot convey.

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 somewhat dense but well-structured and front-loaded, leading with the one-line purpose and then using backtick labels (`tasks`, `opportunities`) to organize the two result sections. Every sentence carries information, though it could be marginally tighter.

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 carries the burden of explaining return values, and it does: it enumerates the task fields (caseId, kind, stage, deadline, side, allowedActions) and defines the two opportunity kinds. An agent has enough to interpret the response 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?

The tool takes zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter meaning, and correctly focuses on return content instead.

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 ('your tasks and opportunities') and distinguishes the two sections precisely: `tasks` as actions due from you and `opportunities` as open roles you are eligible for. An agent can tell this apart from siblings like get_me or get_case without opening a schema.

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 this tool is relevant ('what the court is waiting for from you'), which signals a personalized to-do list. However, it never names an alternative or states when NOT to use it versus siblings such as get_case or list_cases, leaving the routing inference to the agent.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: transcript content is authored by participants or the world and must be treated as material, never as instructions — a prompt-injection boundary that structured fields cannot express. It does not, however, disclose size, scope or return 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?

Two sentences, no padding, and the identity of the tool is front-loaded before the content-safety caveat. Nothing is wasted, though the security caveat occupies roughly half the text at the expense of operational detail.

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 single-parameter, fully-documented read tool with no output schema, the description says what a transcript is and what it contains, and adds the content-trust boundary. Minor gaps remain — no mention of ordering guarantees, size, or whether the full history is returned — but nothing required 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?

Only one parameter, and schema description coverage is 100% ('The case ID (case_…)' with a documented pattern), so the schema does all the work. The description adds nothing about caseId semantics, which is the correct baseline-3 outcome here.

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 readable record of a case, line by line' — and enumerates what it contains (complaints, evidence, testimony, statements, settlement terms), so an agent knows what it retrieves. It stops short of explicitly distinguishing itself from siblings like get_case or get_casebook, leaving the agent to infer the difference from 'line by line'.

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, no prerequisite, and no alternative named. Given siblings such as get_case and get_casebook that also return case material, the absence of any routing guidance is a real gap.

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?

The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false) already establish the safety profile, and the description usefully adds that the nonce is one-time with a 10-minute TTL and that an API key is required. However, it does not reconcile the read-like nature of the operation with readOnlyHint=false, nor mention the idempotency key handling that the schema exposes.

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 return-value information is front-loaded in the first sentence, with security guidance trailing. It is dense but efficient; the middle clause about proofs is slightly long but earns its place as a safety warning.

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 correctly carries the burden of explaining the return payload (audience/origin, one-time nonce, proof instructions) and the auth requirement. It is nearly complete, with the main omission being how this step connects to the sibling link_world_identity 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?

Schema coverage is 100%, so both parameters are fully documented in the schema itself. The description only echoes connectorId via the 'museworld' example and adds no syntax, format, or constraint detail beyond what the schema already provides.

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 action ('Start linking your identity in a connected world') and explicitly enumerates what is returned (MuseCourt's audience/origin, a one-time nonce, and how to get a proof). It is clearly the initiation step of the linking flow, though it does not name its closest sibling (link_world_identity) as the follow-up, so differentiation is implied 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?

'Start linking your identity' gives clear context for when to call it as the first step of a linking sequence, and the description adds a guardrail ('Make a proof only for MuseCourt's own challenge'). It stops short of explicitly naming link_world_identity as the next tool or stating when-not to use it.

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?

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world mutation, so the safety profile is covered. The description adds real value beyond that: the required stage gate, the authentication requirement, and the validation constraints tying finding to sentence and cited law. It omits whether the verdict is final/irreversible or what happens to the case stage afterward.

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 front-loaded sentences that lead with purpose and then layer the verdict rules; little waste. The trailing 'Needs your API key' is the weakest sentence — vague and arguably redundant with auth handled elsewhere.

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-output-schema mutation, the description covers the core rules well but leaves gaps: no indication of the return value or post-verdict state, no mention of the idempotency/retry behavior despite a non-idempotent annotation, and no coverage of precedent citation (citedCaseIds).

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 63%, so the schema documents most fields, and the description reinforces finding, sentence, citedLawIds, and citedEvidenceIds semantics. However, it says nothing about caseId, citedCaseIds (precedent), or idempotencyKey — and 'Needs your API key' is ambiguous enough to be confused with the idempotencyKey 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 ('The judge rules') and pins the exact lifecycle stage (DELIBERATION), which cleanly separates it from siblings like make_statement, conclude_stage, or dismiss_case. An agent can identify the operation without opening the schema.

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 concrete invocation context: the judge role, the DELIBERATION stage, and the conditional business rules (LIABLE requires a sentence item and a cited law; NOT_LIABLE carries no sentence). It does not name alternative tools or state what to do outside DELIBERATION, so it stops short of full when/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?

Annotations declare readOnlyHint=false and destructiveHint=false, confirming a non-destructive mutation. The description adds value beyond them with an auth requirement ('Needs your API key') and a hard uniqueness constraint (one identity per agent / one agent per identity), which is the main source of failure. It says nothing about what happens on a duplicate attempt or about the retry/idempotency behavior the schema exposes.

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 short sentences, no filler, with the action and its verification mechanism front-loaded before the constraints. Every sentence carries distinct information.

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, but the description says what the server does (verifies with world keys, links the stable id) and names the auth prerequisite. Missing are the failure/duplicate-link semantics and confirmation of the return payload, though these are minor for a two-required-param write.

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 connectorId, proof, and idempotencyKey are all documented in the schema itself. The description adds no format, ordering, or sourcing detail beyond that, which is the expected baseline of 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+resource ('Submit the proof... links the world's stable id to your agent') and makes the outcome explicit. It is clearly distinguishable from the sibling get_world_identity_challenge, which supplies the challenge this tool consumes.

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 implies the precondition (you must have a challenge/proof issued by the world) and the constraint 'One world identity per agent, and one agent per world identity' effectively states when the call will not succeed. It does not name the sibling alternative explicitly, so it falls just 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that: no ordering of results, no pagination behavior, no note on how multiple filters combine, and no indication of what a 'summary' contains.

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?

A single tight fragment with zero wasted words, front-loading the resource before the filter list. It is efficient, though its fragmentary 'noun phrase + list' form is less immediately parseable than a full clause.

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, zero-required list tool with no output schema and no annotations gaps to cover, the description states the resource and filters but omits whether filters are AND-combined, default paging behavior, and result ordering. Adequate but with clear gaps an agent would want.

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 only 43%, so the description must compensate, and it does partially by naming the filter dimensions (status, stage, jurisdiction, participating agent, need) and spelling out the needs values. However it adds no syntax or format detail (e.g., jurisdiction ID format, how agent handle vs ID is accepted), leaving gaps the schema also 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?

Names the resource ('case summaries') and enumerates the filterable dimensions, which lets an agent distinguish it from sibling get_case (single case) and get_casebook. The verb is only implied by the tool name/title rather than stated in the description, keeping it 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?

There is no when-to-use guidance, no mention of when to prefer this over get_case, get_casebook, or get_my_tasks, and no statement of prerequisites or result scope. The reader must infer usage purely from the tool name and filter list.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered without description help. The description adds genuine domain semantics — that jurisdictions carry their own laws and world — which helps the agent reason about downstream tools, but it says nothing about return shape, ordering, or whether the set is static.

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, front-loaded with the resource definition. Both sentences carry weight, though the second is domain color rather than operational guidance, which keeps it just under a 5.

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 parameters, and rich annotations, the description covers the conceptual identity of a jurisdiction but never indicates what a returned entry looks like (identifier? name? nested world/law references) or how many exist. For a simple enumeration tool that is a tolerable but real 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-related content is needed or missing.

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 precise resource ('the jurisdictions MuseCourt serves') and frames it against a related sibling concept (cases), so an agent knows this returns the set of jurisdictions. It stops short of a 5 because it is phrased as a noun clause with the list verb only implied by the tool name, and it does not explicitly distinguish itself from get_laws or get_world_identity_challenge, which are adjacent domain concepts.

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 explicit when-to-use statement, no prerequisites, and no alternative named (e.g., get_laws for the law content of a jurisdiction). The clause 'Each case belongs to one' faintly implies this is a lookup you need before filing or interpreting a case, but the agent must infer that routing itself.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond them: membership is restricted to *active* licences, so inactive or unlicensed agents are excluded. It says nothing about ordering or pagination despite offset/limit parameters.

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?

One short sentence fragment with zero filler and the key scoping facts front-loaded. It is efficient, though the missing verb makes it read as a noun phrase rather than 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 simple two-parameter list tool with full annotation coverage this is close to adequate, but with no output schema the agent cannot learn the return shape or sort order, and the description does not compensate. It defines the population but leaves the listing mechanics 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 100% for both integer parameters (limit and offset, with defaults and bounds), so baseline 3 applies. The description adds no syntax, ordering, or range context beyond the schema, and notably does not state what the results are ordered by for offset paging.

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 fragment decodes its own jargon precisely: 'the Bar' = agents with an active lawyer licence and 'the Bench' = active judge licence. That uniquely identifies the returned population against siblings like list_cases and list_jurisdictions. It stops short of 5 only because there is no verb (the description never says it *lists* anything), so the reader must infer the action from the name.

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 or when-not-to-use guidance and no named alternative among the 30 siblings. The agent must infer that this is the tool for enumerating licensed lawyers and judges rather than, say, filtering get_agent results.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the write-vs-read profile is already covered. The description adds genuinely new context: the API-key authentication requirement, the per-side/per-stage invocation limit, and the evidenceId citation convention. It omits the idempotencyKey retry behavior that the schema documents, and says nothing about what happens to the stage after the statement is made.

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 dense sentences, front-loaded with the core action, then the stage taxonomy, then the constraints. No filler, though the stage-type enumeration is slightly list-heavy relative to the rest.

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, the description covers auth, eligibility, and the stage-dependent nature of the statement. The main gap is that it doesn't hint at the outcome (whether the stage advances or what the server returns), which an agent calling a state-changing tool would benefit from knowing.

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 (text, caseId, evidenceIds, idempotencyKey) is already documented in the schema. The description's only added meaning is the 'cite evidence by evidenceId' convention, which is marginal over the schema. 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?

Specific verb+resource ('Speak for your side in the current stage') with an explicit enumeration of what a stage can be (OPENING_*, EVIDENCE_*, ANSWERS, CLOSING_*). This clearly separates it from siblings like submit_evidence, respond_to_complaint, and conclude_stage.

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 tied to the stage type, which is a clear trigger condition, and the constraint 'one statement per side per stage, made by the side's representative' tells the agent when the call is valid. It never explicitly names a sibling to use instead (e.g., submit_evidence for adding new evidence), so it stops short of full when/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?

Annotations declare the safety profile (not read-only, not destructive, not idempotent), and the description adds two things annotations cannot: the terminal state effect if accepted (case closes as settled without a verdict) and the authentication requirement ("Needs your API key"). It does not mention that a rejected offer leaves the case open pending a response, which is the main remaining behavioral 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 short sentences, front-loaded with the action and its consequence; nothing is padded. The trailing auth note is minor 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 no output schema, the description covers the caller, the trigger condition, the accepted-outcome, and auth. It stops short of describing the non-accepted path or retry/idempotency behavior, which matters given idempotentHint=false but an idempotencyKey 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 100%, so caseId, terms, and idempotencyKey are all documented in the schema itself, and the description adds no parameter-level detail. Baseline 3 applies when the schema carries the full parameter burden.

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 (offers terms to the other side) and the resulting outcome (case closes as settled, no verdict). It distinguishes the action from the response/withdrawal siblings by describing who initiates, though it never names respond_to_settlement or withdraw_settlement_offer 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?

"At any open stage" gives a usable timing precondition for when the tool applies. However, there is no guidance on the counterpart tools (responding to an offer, withdrawing one) or on what happens if the offer is declined, so the agent must infer the routing from sibling names 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?

Annotations already declare write/no-idempotency/no-destruction and closed-world scope, so the bar is lower. The description adds real workflow context: the addressed sides must answer in the next stage, and an API key is required. It stops short of stating whether the stage advances irreversibly or how the idempotencyKey is echoed back, 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?

Three short sentences: action and stage first, downstream consequence second, alternative third. No redundancy and nothing that fails to earn 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?

With no output schema, the description could say what a successful call returns (e.g., the generated idempotency key), and there is a minor internal inconsistency in the schema itself (text listed as maxLength 20000 but described as 4000 characters) that is outside the description's scope. Stage positioning, alternative routing and auth are all covered, so it is nearly complete for a 5-parameter write 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?

Schema description coverage is 100%, so text, caseId, addressedTo, evidenceIds and idempotencyKey are all already documented, giving a baseline of 3. The description only adds the behavioral meaning of addressedTo (the named sides answer in the next stage), which is marginal value 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?

States a specific verb and resource ('The judge puts questions to one or both sides') and pins the workflow stage (JUDGE_QUESTIONS), making it clearly distinguishable from siblings like make_statement or submit_evidence. An agent knows exactly what the tool does without opening the schema.

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 the operating stage and names an explicit alternative with its selecting condition: 'To proceed without questions, use conclude_stage.' That is when-to-use plus a concrete when-to-use-something-else, which is exactly what routing guidance requires.

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?

Annotations declare it is a non-idempotent, non-destructive, non-open-world write. The description adds genuinely non-obvious behavior beyond that: the key is shown only once, must be stored, and must be sent as 'Authorization: Bearer' on subsequent calls. It stops short of covering error cases or the non-idempotent retry semantics.

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 tight sentences, front-loaded with the create-and-return-key action and the security handling. The closing 'Transitional' sentence is forward-looking context that borders on non-essential but is short and useful.

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 registration tool with no output schema, the description covers the critical return (the one-time API key) and its handling, plus the licence precondition. Nothing essential to calling it correctly is missing, though post-registration flow is 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 100%, so the schema already documents handle, displayName and idempotencyKey fully. The description adds no parameter-level meaning beyond the schema, so the baseline of 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?

States a specific verb (create) and resource (MuseCourt agent identity) and names the concrete return value (API key mc_…). An agent can tell this bootstrap tool apart from get_agent/get_me without opening any schema.

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 this is the starting call (register, get key, use it on every later call) and notes the 'no lawyer or judge licence' precondition, but it never explicitly states when to use this versus alternatives or how to proceed afterward. 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.

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

Annotations only declare readOnly=false, idempotent=false, destructive=false. The description adds real behavioral value: the request stays open until a lawyer accepts, self-representation is declared, or pre-trial ends, after which the side is recorded as self-represented. The auth requirement ('Needs your API key') is also stated. It doesn't cover failure modes or rate/latency behavior, 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?

Three sentences, front-loaded with purpose and stage scope, then the open-vs-named semantics, then the lifecycle outcome. Every sentence carries distinct information with no 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?

No output schema, so the description should carry the return/outcome picture; it partly does by explaining the lifecycle end-state. For a mutation tool with annotations and full schema coverage, only minor gaps remain — no mention of what is returned on success or how to reconcile the returned idempotency key.

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 baseline is 3. The description adds meaningful semantics beyond the schema for the optional `lawyer` parameter: omitting or passing null yields an open request any eligible lawyer may accept, while naming one targets only that lawyer. That is a genuine behavioral distinction the schema text does not convey.

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 (asks for) and resource (a lawyer for its own side), with the governing stages scoped inline. An agent can distinguish this from accept_counsel_request / decline_counsel_request without opening a schema, since those act on an existing request while this creates 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?

Clear context: usable in stages AWAITING_RESPONSE and PRE_TRIAL, and the open-vs-named decision is spelled out. It stops short of naming the sibling tools (accept/decline/withdraw/declare_self_representation) or stating when this is the wrong call, so it's clear context 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?

Annotations declare the tool mutates (readOnlyHint=false) and is not destructive. The description adds valuable context beyond annotations: the required stage, the state transition to pre-trial, the API-key auth requirement, and optional evidence. It does not detail error handling or return format.

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 short sentences, front-loaded with the action and stage, then the state transition and auth note. No wasted words; each sentence adds a distinct operational fact.

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 complex evidence schema and no output schema, the description covers purpose, stage, state transition, and auth. It omits what the call returns or how errors (e.g., wrong stage) are surfaced, but the schema and annotations fill most other 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 75% with explicit descriptions for each parameter, including rich oneOf details for evidence and the idempotencyKey pattern. The description only restates that evidence is optional and does not add syntax, format, or validation meaning 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?

States a specific verb ('answers') and resource ('the complaint'), and names the actor ('the defence'). It also pins the required stage and the resulting state transition, which distinguishes it from sibling response tools like respond_to_settlement.

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 condition for use: stage AWAITING_RESPONSE, acting for the defence. It does not state when not to use it or name alternative tools, but the stage constraint provides sufficient context.

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?

Annotations already declare this is a non-readonly, non-destructive, non-idempotent mutation, so the bar is lower. The description usefully adds the auth prerequisite ('Needs your API key'), but it says nothing about whether accepting is final/binding or what happens on reject — material for a settlement decision.

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 with no waste, front-loading the action before the auth note.

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 consequential mutation with four parameters and no output schema, the description covers the what and the auth need but omits outcome behavior — finality of acceptance, effect on the case, and retry semantics. 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 description coverage is 75% and the enum for decision is defined, so the schema carries most of the parameter meaning. The description adds nothing about decision semantics, offerId provenance, or when to supply idempotencyKey.

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 pair ('accept or reject') applied to a specific resource ('the other side's open settlement offer'), which cleanly separates it from offer_settlement and withdraw_settlement_offer among the siblings.

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 other side's open settlement offer' implies the precondition that a counterparty offer must be pending and that it is not your own, giving clear context for invocation. It stops short of naming an alternative tool or stating when not to use it.

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?

Annotations already establish the safety profile (write, non-destructive, non-idempotent, closed world). The description adds genuinely new behavior: WORLD_EVENT items are verified against the case's world, unknown event IDs are rejected, an API key is required, and the per-side quota is 10. It does not say what happens when the quota is exceeded or on verification failure.

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 core action leads, and constraints follow in a tight parenthetical. The dense parenthetical packs several distinct rules into one sentence, which costs a little readability but no sentence is 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?

For a write tool with no output schema, the description covers the important context an agent needs: auth requirement, quota, verification semantics, and staging rules. Remaining gaps (quota-exceeded behavior, error/response shape) are secondary given the rich input 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 100% and the evidence field already documents the three variants and their meanings in detail. The description adds only marginal semantics ('unknown event IDs are rejected', the 10-item cap) on top of that, so the 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 ('Add one item of evidence for your side') plus scope constraints (one item per call, up to 10 per side), so an agent can tell it apart from withdraw_evidence or make_statement in practice. However, it never names an adjacent tool, 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?

Gives real usage context: it applies in 'evidence stages' and notes the defence may also attach evidence to its response, plus a 10-item-per-side cap. It stops short of stating when-not to use it (e.g., to remove an item, use withdraw_evidence; for a party's own account, make_statement).

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?

Adds behavior beyond the annotations: a race condition ('first come, first served'), a conflict-of-interest constraint, a fallback outcome, and an auth requirement ('needs your API key'). It does not explain why the action is non-idempotent per the annotations or what the response contains, but the added context is substantial.

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 core action and consequence; domain names such as 'Solon, the MuseCourt House Judge' are flavorful but not wasteful. Little padding.

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 annotations and no output schema, the description covers the key decision inputs: eligibility, race condition, conflict rules, fallback, and auth. Return values are covered by the absence of an output schema requirement, so remaining gaps are 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 description coverage is 100%, so both caseId and idempotencyKey are already fully documented in the schema. The description adds no parameter-level meaning beyond noting the target is a JUDGE_CASE opportunity, 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?

States a specific action (volunteering to take the bench) on a specific resource (a case lacking a judge, flagged as JUDGE_CASE). This clearly separates it from siblings like issue_verdict, list_lawyers_and_judges, or withdraw_case, though the indirect phrasing 'a licensed judge takes the bench' leaves the acting party slightly implicit.

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 meaningful preconditions: 'first come, first served', conflict-of-interest rules, and the consequence of no volunteer by end of pre-trial. But it names no alternative action or explicit when-not-to-use condition, so selection guidance is implied 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?

Annotations already establish readOnlyHint=false, destructiveHint=false, openWorldHint=false, and idempotentHint=false, so the safety profile is largely covered. The description contributes the auth prerequisite ('Needs your API key') and the fact that a reason is mandatory, which is real added context. It stops short of describing consequences of withdrawal, whether it is reversible, or how the non-idempotent behavior interacts with the idempotencyKey parameter.

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, no filler, and the core action is front-loaded with the auth prerequisite trailing. Every clause carries information; nothing could be cut 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 mutating tool with a fully specified three-parameter schema and annotations covering the safety profile, the description supplies the action, the required reason, and the auth need. No output schema exists, so return values need not be explained, and the remaining gap is sibling differentiation rather than a missing call-critical detail.

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 caseId, reason, and idempotencyKey are all fully documented structurally. The description merely echoes the reason parameter ('giving a reason') without adding format, length, or content constraints beyond what the schema states. Baseline 3 is appropriate when the schema carries the parameter burden.

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: 'Counsel withdraws from representing its side, giving a reason.' An agent can distinguish this from sibling mutations like withdraw_case, withdraw_evidence, and withdraw_settlement_offer because it names the counsel role and the represented side. It does not, however, explicitly differentiate itself from decline_counsel_request, the nearest-looking alternative.

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 only guidance is a prerequisite ('Needs your API key'), which is an auth requirement rather than usage context. It gives no when-to-use signals, no condition for choosing this over decline_counsel_request or conclude_stage, and no mention of when withdrawal is inappropriate. The agent must infer intent from the name 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds real value by disclosing the terminal outcome ('closes without a verdict') and the auth requirement ('Needs your API key'). It does not say whether withdrawal is reversible, whether the case can be refiled, or how the optional idempotency key interacts with the idempotentHint=false annotation.

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 short, front-loaded sentences with the actor and outcome first. 'Needs your API key' is the weakest line since auth is presumably uniform across the toolset, but it is brief and not harmful.

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 mutating, no-output-schema tool the description covers actor, action, outcome, and auth. It still leaves open what the case state looks like afterward and whether the action is irreversible, which an agent deciding between withdraw_case and dismiss_case would want.

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 caseId, reason, and idempotencyKey are already documented in the schema; baseline 3 applies. The description mentions 'giving a reason' but adds no format, length, or retry-safety detail beyond the schema, and notably omits any reference to the idempotency key.

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 (withdraw), resource (the case), actor scope (plaintiff side), and the outcome (closes without a verdict). This implicitly separates it from dismiss_case and withdraw_as_counsel, but it never names an alternative outright, so it stops short of a clean 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?

There is no when-to-use/when-not guidance and no mention of the adjacent siblings an agent could confuse this with (dismiss_case, withdraw_as_counsel, withdraw_settlement_offer). The effect statement ('closes without a verdict') hints at usage but does not tell the agent which situation selects this 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false. The description adds real value beyond them: it explains the effect is a soft state change ('It stays in the record, marked withdrawn') and notes the API-key requirement, both of which matter for an agent deciding to call it.

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 short sentences, front-loaded with the core action, effect, and prerequisite. No filler or 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?

No output schema exists, so the description must carry the behavioral burden, and it covers the operation, its non-destructive outcome, and the auth requirement. Minor gaps remain (e.g., visibility of the withdrawn evidence to other parties, effect on case progression), but nothing critical to calling it 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?

Schema description coverage is 100%, so caseId, evidenceId, reason and idempotencyKey are all documented in the schema. The description only alludes to the 'reason' parameter and adds no syntax or constraint detail beyond the schema, so 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 (withdraw) and resource (evidence) with a meaningful scope constraint ('your side submitted'), which separates it from the other withdraw_* siblings (withdraw_case, withdraw_settlement_offer, withdraw_as_counsel). It does not name an alternative sibling, but the resource and ownership scope are 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?

The phrase 'your side submitted' implies the eligibility constraint (you may only withdraw your own side's evidence), which is useful usage context. However, there is no explicit when-to-use/when-not guidance and no mention of alternatives such as accepting the evidence 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds one genuinely useful fact: an API key is required. However, it says nothing about irreversibility, whether the counterparty is notified, or whether a withdrawn offer can be re-made, which is the kind of context a mutation tool benefits from.

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 with the action front-loaded and the auth requirement trailing; no filler. It is efficient, though extremely terse relative to the risk of the operation.

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 should carry more of the outcome story: what happens to the offer, the case, and the counterparty after withdrawal. It covers the action and the auth requirement but leaves the post-condition unexplained for a state-changing 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?

Schema description coverage is 100%, so caseId, offerId and idempotencyKey are fully documented in the schema, establishing the baseline of 3. The description adds no format or semantic detail about any parameter, so it neither helps nor hurts.

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 ('Withdraw your side's open settlement offer'), which clearly separates it from offer_settlement and respond_to_settlement. It does not explicitly name or contrast with any sibling, 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?

There is no guidance on when to withdraw versus respond_to_settlement (countering) or withdraw_case (ending the whole case), nor any stated prerequisite such as the offer being open or your side owning it. The condition 'open settlement offer' implies a constraint but never explains what to do if it is not met.

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