Unified Chambers Legal

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

Annotations declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description adds real side-effect detail: emails the booking to legal@unifiedchambers.com with a copy to the Senior Partner's mailbox plus an acknowledgement to the user. It does not address duplicate-submission behavior, which matters for a non-idempotent write tool.

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

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

Two sentences, no filler. The precondition ('after the user has paid') and the core payload are front-loaded, and the side-effect and scope-disclaimer clauses follow in the order an agent needs them.

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 10-parameter, 8-required non-idempotent write with no output schema, the description covers the flow, the precondition, and the downstream emails adequately. It is silent on failure/duplicate handling and on what the caller receives back, which is a minor gap given no output schema exists.

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

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

Schema description coverage is 100%, so all ten parameters, both enums, and the slot format are already documented in the schema. The description lists the same fields but adds no format, constraint, or validation meaning beyond it, 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 and resource — records a consultation booking — and enumerates exactly what the booking consists of (name, phone, matter type, summary, UTR, preferred date/slot). The closing line 'Does not make or verify any payment' cleanly separates it from the sibling payment tool, so an agent can route between them without opening either 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 a clear precondition: this is used only after the user has paid the fee from their own bank app. The negative clause 'Does not make or verify any payment' functions as a when-not. However, no sibling is named explicitly (e.g. consultation_payment_details for collecting the fee), so the routing is inferred rather than stated.

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

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

Annotations declare writability, open-world behavior and non-idempotency, but the description adds real value beyond that: it names the recipients (panel firm address plus Senior Partner copy), the panel register entry, and the acknowledgement email to the signed-in address. It does not warn that repeat calls create duplicate briefs despite idempotentHint=false, which keeps it from a 5.

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

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

Side effects and the usage condition are front-loaded in two efficient sentences with no filler. The enumeration of destinations is slightly dense but every clause carries information an agent needs before invoking a mutation.

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 six-parameter mutation with no output schema, the description covers purpose, recipients, register side effect, and the acknowledgement that serves as implicit confirmation. It omits any statement of what the tool returns on success and any permission or validation requirements, which are the remaining 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 100%, so the schema already documents all six parameters including the 1,200-character summary cap, the security enum, and the forum options. The description restates the same fields without adding format or validation meaning beyond what the schema provides, 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 and resource — 'Sends a new recovery account to the institution's panel counsel as a written brief' — and enumerates the payload (borrower, claim amount, security position, forum, summary, documents). This is clearly distinguishable from siblings such as send_matter_enquiry or book_consultation without opening either 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?

'Use when the institution wants to instruct its panel counsel on a new account' gives a clear triggering condition. It does not name an alternative or state when NOT to use it (e.g. for an existing matter, use send_matter_enquiry), so it stops short of a 5.

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

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

Annotations already establish this as a pure, idempotent, non-destructive read. Beyond that, the description discloses actual output content — the prescribing rule is cited, and for DRAT appeals the appeal period and statutory pre-deposit are also returned. That is meaningful behavioral detail the 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?

Two tight sentences: the capability and its three cases come first, then the trigger condition. No filler, no restating of the title, and every clause carries 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, so the description must hint at returns; it does so by naming the cited rule, appeal period, and pre-deposit. It stops short of describing the applicant-driven dual-fee output, but for a deterministic calculator this is nearly 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% and the schema already spells out what amount_inr means per filing type, so the baseline is 3. The description adds only the general framing ('from the amount of debt') and does not mention the applicant parameter or the both-fees-shown fallback.

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

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

The description states a specific verb ('Calculates') and resource ('the court fee prescribed') and enumerates the three exact filing scenarios it handles (DRT original application, SARFAESI Section 17 application, DRAT appeal), matching the schema enum. No sibling tool covers fee calculation, and the scope is unambiguous.

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

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

It gives an explicit usage trigger: 'Use when someone asks what it costs to file before the DRT or DRAT.' That is clear context, but it offers no when-not guidance and does not name alternatives (e.g. pointing to sarfaesi_timeline or find_drt_bench for adjacent questions).

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. The description adds the specific return contents and reinforces that no payment is executed, which is valuable because no output schema exists; it does not cover auth or freshness.

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 compact sentence lists the returned items, followed by a short behavioral note. It is front-loaded and every sentence earns its place.

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

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

For a zero-parameter, read-only info tool with rich annotations, the description adequately explains what is returned and that no payment occurs. It leaves unclear how the tool identifies the scheduled consultation without parameters, a minor contextual gap.

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

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

The tool has zero parameters, so the baseline is 4. Schema coverage is vacuously 100% and the description adds nothing parameter-related, but no parameter clarification is needed.

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

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

States a specific verb 'Returns' and specific resource: fee, coverage, bank account/UPI QR, and booking steps. It distinguishes itself from book_consultation implicitly but does not explicitly name the sibling, which keeps it from 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?

No when-to-use guidance, no alternatives, and no conditions for invoking this tool. The only usage-adjacent statement is 'Read-only; makes no payment,' which is a behavioral constraint rather than selection 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 readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. Beyond this, the description discloses the output behavior — sorted by due date, flagged when due within 7 or 14 days — and the batch cap of 50. Does not mention error behavior for invalid event/date combinations, but adds meaningful behavioral context.

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

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

Front-loads purpose, then scope, then output behavior, then usage. The middle sentence listing legal regimes is dense but relevant. Overall appropriately sized for a tool with a moderate-sized schema, with only mild redundancy around the regimes mentioned in both description and schema.

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

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

Given read-only annotations, a fully documented schema, no output schema, and the description's disclosure of sort order and due-date flagging, an agent has enough to invoke correctly. Lacks explicit mention of the return shape per account (e.g. fields in each result), which is the only minor gap.

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

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

Schema description coverage is 100%, including detailed per-event documentation in the enum, so the baseline is 3. The description reinforces the 'from an event and its date' pairing and the 50-account cap but does not add semantics the schema doesn't already provide.

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 ('Computes the due date of a statutory period for each of up to 50 recovery accounts') and enumerates the legal regimes covered (SARFAESI, DRAT, NI Act). Distinguishes itself from siblings like sarfaesi_timeline and panel_deadline_tracker by virtue of the multi-account batch scope.

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

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

Provides clear context ('Use to build or check a deadline list across several accounts') but does not name explicit alternatives or exclusions relative to sarfaesi_timeline, which appears to be a closely related sibling. Gives intended use without a when-not-to-use clause.

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 and closed-world behavior, so the safety profile is covered. The description adds real value beyond that by enumerating the returned payload (definition, example, statutory reference, practice note, related terms) and disclosing that the source is a curated 111-term glossary, which implies coverage limits. It does not say what happens for a term outside the glossary.

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 tightly written sentences with zero filler: scope and returned content first, then the triggering use case and examples. Every clause earns its place.

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

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

With no output schema, the description adequately compensates by listing what a definition returns and bounding the source glossary. The only gap is behavior for unknown/out-of-glossary terms, which an agent might reasonably want before calling.

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 a single, well-documented parameter, so the baseline is 3. The description's examples of valid terms overlap with the schema's own examples rather than adding new syntax or format guidance.

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 ('Defines an Indian legal term') plus the exact source scope: a curated glossary of 111 terms across eight named practice areas. An agent can immediately separate this glossarial lookup from sibling tools like lookup_bare_act_section, search_bare_acts or find_rbi_nbfc_direction.

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 trigger condition ('Use when the user asks what a legal term or abbreviation means') with concrete examples (NPA, CIRP, Recovery Certificate, Garnishee Order). It stops short of naming an alternative tool or stating exclusions, e.g. when to prefer a bare-act section lookup 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: results include each bench's official-registry address plus its appellate tribunal, and the empty-input case returns every seat grouped by DRAT. No auth or rate-limit notes, but the key behavioral modes are disclosed.

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 the core purpose, followed by concrete use cases and then the no-argument fallback. No filler or repetition, and the most decision-relevant information comes 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?

With no output schema, the description carries the burden of explaining returns and does so: bench addresses from the official registry, the DRAT that hears appeals, and the full-seat listing when unfiltered. Nothing an agent needs to invoke this 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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'used when no city is given, or to tell apart places with the same name' note for state. The description restates the same semantics at a higher level rather than adding syntax, format, or matching rules, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Finds the Debts Recovery Tribunal (DRT) bench or benches') and expands the domain to include addresses and the linked DRAT. An agent can immediately distinguish this from siblings like find_rbi_nbfc_direction or sarfaesi_timeline 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?

It gives explicit trigger questions ('which DRT a city falls under, where a DRT sits, or which DRAT hears appeals') and states the fallback behavior when no city or state is supplied. It does not name or exclude any sibling alternative, but usage context is clear.

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 closed-world (openWorldHint=false). The description reinforces the closed corpus ('held in this dataset') and, unusually, discloses the returned fields (reference, date, summary, page and PDF links), which the annotations do not cover. Pagination and result-count behavior remain undisclosed, keeping it below a 5.

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

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

Two sentences, both earning their place: the first front-loads the resource, scope and return shape, the second delivers the usage trigger. No filler or repetition of the title.

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 compensates by enumerating the return fields, and both parameters are fully documented in the schema, so an agent can call this correctly. It could still say what happens with zero matches or how results are limited, and it does not route between the other search-family siblings.

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%: the query parameter's format and the full category enum-to-label mapping are already documented in the schema. The description only echoes that matching happens by topic, reference number or category, adding no syntax or constraint detail 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 and resource ('Finds the RBI Master Directions for ... NBFCs held in this dataset') plus the match dimensions (topic, reference number, category). It is distinguishable from sibling search/lookup tools such as search_bare_acts and lookup_bare_act_section, which target bare acts rather than the NBFC Master Directions corpus.

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

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

Gives clear context for use ('Use for NBFC regulatory-compliance questions') with concrete examples of the topics covered (fair practices, KYC, provisioning, registration). It stops short of naming alternatives or when-not-to-use cases, so it falls just below the explicit routing bar.

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, and non-destructive, so the safety profile is covered. The description adds useful content scope (register entry plus recorded deadlines) but says nothing about error behavior for invalid IDs, permissions, or pagination. With annotations carrying the safety burden, this is an adequate but thin addition.

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 with no filler; the what (full register entry with deadlines) is front-loaded and the how-to-use sentence follows immediately. Every clause earns its place.

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

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

With no output schema, the description correctly compensates by naming what is returned: the register entry and its recorded deadlines. Combined with a fully documented single parameter, an agent has enough to call it correctly; only error/edge-case behavior is unstated.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents matter_id and even its originating tool. The description simply restates that identification is by matter ID, adding no format or constraint 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 verb and resource ('Returns the full register entry for one of the institution's matters') and pins the scope to a single matter by ID. It implicitly distinguishes itself from list_my_matters by describing a single-record deep read, though it never explicitly contrasts the two.

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 sequencing guidance: 'Use after list_my_matters to examine a single account,' naming the prerequisite tool and the condition (single-matter drill-down). It stops short of stating when not to use it or what happens for an unknown ID.

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, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral detail: the scope is the signed-in user's institution, results are ordered soonest hearing first, and the default filter is active. It stops short of pagination or result-count 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?

Two sentences, front-loaded with the resource and scope, then the returned fields, ordering, and filter. Dense but every clause carries information; the trailing 'Use for...' sentence is the only slightly soft element.

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 helpfully enumerates the returned fields (forum, bench, case number, stage, next hearing, last update, claim amount) and ordering, which is exactly what an agent needs. For a read-only single-enum-param list tool this is nearly complete; pagination/limits remain unspecified.

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

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

Schema description coverage is 100% and the single enum parameter is fully documented in the schema itself, so the base score is 3. The description restates the same three status values and default without adding syntax or edge-case 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 (lists) and resource (matters on the panel matter register) with scope (signed-in user's institution) and enumerates the returned fields plus sort order. An agent can distinguish it from siblings like get_matter_status or upcoming_hearings 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?

The final sentence gives a usage context ('overview of the institution's matters with its panel counsel') and the status filter semantics are explained, but no alternatives such as upcoming_hearings or get_matter_status are named, and no when-not-to-use is stated. Usage is implied rather than routed.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description adds real substance beyond that: curated provenance ('firm's annotated bare-acts library, reproduced from the enacted Act'), explicit coverage boundaries, and the hedge 'where recorded', which signals that optional fields may be absent. It does not say what happens when a section is not found in the dataset.

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

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

Front-loaded with the return payload, which is correct, but the parenthetical list of all 20 Acts is a near-verbatim duplication of the enum already in the schema and consumes roughly half the text. The remaining sentence is efficient; the act inventory does not earn its space.

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

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

There is no output schema, so the description must describe the return shape, and it does so field-by-field (section text, explanation, practitioner note, penalty, cross-code section, amendment history). Combined with the 100%-covered input schema this is nearly complete; the only omission is not-found/empty-result behavior for a cited section outside the 20 Acts.

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%: both parameters and every enum value are documented in the schema, so the baseline is 3. The description repeats the Act coverage list without adding format or syntax beyond the enum, and adds only the minor note that BNS/BNSS enacted headings are available. No extra meaning for the 'section' parameter beyond the schema examples.

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 ('Returns a section of an Indian Act') with an unusually concrete enumeration of the payload: section text, plain-English explanation, practitioner note, penalty, old/new-code section, amendment history. The scope is clearly bounded (a single cited section, 20 named Acts). It stops short of naming the siblings it must be distinguished from (search_bare_acts, map_old_code_section), so the differentiation is only 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?

The closing line 'Use when a user cites or asks about a specific section or article' gives a clear triggering condition. However, there are no exclusions or alternative routing, even though map_old_code_section (which this tool partly duplicates by returning the corresponding old/new-code section) and search_bare_acts are obvious near-neighbours that the agent must choose between.

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 a safe, idempotent, closed-world read operation, so the safety burden is off the description. The description still adds behavioral value by disclosing that the response includes the transitional rule alongside the mapping, which goes beyond what annotations say. It stops short of describing behavior for unmatched/invalid sections.

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 verb and resource are front-loaded and the enumeration of the three law pairs is necessary for precision, not padding. The single long sentence is dense and slightly overloaded, but every clause carries meaning.

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

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

For a two-parameter lookup with 100% schema coverage and no output schema, the agent has the source law set, target law set, example query, and a note that the transitional rule is returned. The only shared gap, error behavior for invalid sections, 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 the enum values and example section formats ('420', 'Section 498A', '167(2)') are already documented in the schema. The description corroborates the code pairs but adds no syntax guidance beyond the structured field. 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 (maps) and resource set (repealed criminal law sections to their 2023 successors) and enumerates both the source codes (IPC/CrPC/IEA) and target codes (BNS/BNSS/BSA). This clearly distinguishes it from a generic bare-act lookup, since the tool is explicitly about repealed-to-new-code conversion.

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?

Explicitly states when to use it ('Use for IPC-to-BNS, CrPC-to-BNSS and Evidence Act-to-BSA conversion questions') and gives a concrete example query. It does not name sibling alternatives such as lookup_bare_act_section or search_bare_acts, or state when NOT to use it, so it stops short of the top score.

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 behavioral detail about output composition: it includes the provision each matter runs under, flags items due within 7 days, and lists overdue open items separately within the same day window. It does not cover auth or rate limits, but that is not expected for this tool.

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

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

Two dense sentences with no filler, front-loading the core action and scope. The second sentence handles the past-due edge case without disrupting the main flow.

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 read-only listing tool with one optional parameter, no output schema, and full annotation coverage, the description is complete enough: it explains the window, default, flagging, provision detail, and separate past-due handling. Ordering, pagination, or result-count limits are omitted, but not essential here.

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 'days' parameter is already fully documented in the schema. The description restates the 1–90 range and default 30, and clarifies that the same number of days applies to the overdue window, but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Lists') and resource ('open deadlines in the institution's matters') with clear scope: due within the next N days, default 30, flagging items within 7 days, and separately listing recently passed deadlines. It does not distinguish itself from the sibling tool 'deadline_watch', so sibling differentiation is missing.

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 explicit when-to-use or when-not-to-use guidance is provided, and no alternative sibling tools are named. The agent can infer it is for checking upcoming deadlines, but there is no routing help against 'deadline_watch' or 'upcoming_hearings'.

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 non-destructive, so the safety profile is covered. The description goes further by disclosing what the result contains (each gap with the provision concerned and the penalty provision) and that the check is statutory rather than advisory; it does not discuss auth or rate limits, but none are implied.

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 check is front-loaded in the first clause and the usage trigger closes the description; every phrase corresponds to a real assessment dimension. The single long em-dash sentence is dense but not padded.

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, yet the description tells the agent what comes back (a gap list keyed to provisions plus penalty provisions) and what inputs drive it, which is sufficient for a 7-parameter read-only diagnostic whose parameters are fully documented in the schema.

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

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

Schema coverage is 100% with detailed per-parameter descriptions and enum meanings, so the baseline is 3. The description's enumeration of the seven questions largely restates the parameters (constitution in writing, composition, committee at every office, training, display, annual reporting) and adds only the framing that each maps to a statutory duty.

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 (checks) and resource (an employer's POSH compliance against seven statutory questions under the 2013 Act), and enumerates the exact dimensions assessed. An agent can distinguish this from siblings like lookup_bare_act_section or screen_recovery_matter 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?

Provides an explicit trigger: "Use when an employer asks whether its POSH compliance is in order." That is clear situational context, but it names no alternative tool or exclusion (e.g. when to prefer lookup_bare_act_section or find_rbi_nbfc_direction for adjacent queries).

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 genuine behavioral context beyond that: it says the tool returns enacted wording, states who each period binds, describes what follows when the period ends, and notes it can optionally compute an end date from a start date.

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

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

The purpose and section inventory are front-loaded, and the two closing sentences are short and additive. The middle sentence is dense with a long parenthetical enumeration, but every clause carries statutory mapping information that an agent needs; nothing is 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?

With no output schema, the description carries the burden of describing returns, and it does so concretely: enacted wording, binding party, and consequence after expiry. Combined with the optional end-date computation and clear default ('all'), an agent has everything needed to call and interpret this read-only reference 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 the enum values and date formats are already documented (baseline 3). The description adds extra meaning by stating the computation is optional and explaining that 'from_date' triggers end-date computation, and it frames each enum value against its statutory provision's role.

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

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

States a specific verb ('Lists') and resource ('statutory periods of the SARFAESI Act, 2002'), then enumerates the exact sections covered, making it immediately distinguishable from lookup_bare_act_section and search_bare_acts. An agent knows exactly what it retrieves 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?

The closing sentence 'Use for SARFAESI deadline and limitation questions' gives clear usage context. However, it does not name alternatives or exclusions — e.g., when to prefer lookup_bare_act_section or deadline_watch for the same question — so the routing guidance 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioural context beyond that: the screen reports which routes the facts point to, the bench/DRAT for the place, the periods relevant at the current stage, and flags whether the matter clears a minimum claim-size threshold for engagement.

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 verb and resource, then the output contents, then the usage condition. The first sentence is long and list-heavy but each element is load-bearing; nothing is padded or repeated.

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 carries the return-value burden, and it does enumerate the report's contents well enough to set expectations. It stops short of describing the form of the result (structured screening output vs. narrative opinion), which would fully close the gap for an 8-param analytical 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%, including detailed enum semantics for stage, security, instrument, borrower_type and asking_as, so the schema does the heavy lifting. The description only groups the inputs loosely ('amount, security, instrument, debtor type, place and stage') without adding format or validation nuance, which lands at the baseline 3.

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

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

The description gives a specific verb and resource ('screens a debt-recovery matter from the creditor's side') and enumerates the concrete outputs (SARFAESI, DRT, IBC, cheque-dishonour routes, DRT bench/DRAT, statutory periods, minimum claim threshold). This is clearly separable from siblings like find_drt_bench, sarfaesi_timeline or calculate_tribunal_fee, which each cover only one slice of what this tool aggregates.

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

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

It states the triggering situation clearly ('Use when a lender, company or individual wants a first view of the options for recovering a debt'), which positions it as an entry-point screening tool against more granular siblings. It gives no explicit exclusions (e.g., when to skip it in favour of sarfaesi_timeline for deep timelines), so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-open-world), so the description's added value is the indexed corpus and the result format. Disclosing that it searches library editorial text and BNS/BNSS headings (not just statutes) is meaningful behavioral context. It doesn't mention ranking/pagination behavior, which keeps it at a 4.

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, both load-bearing: the first defines the search surface, the second defines when to reach for it. Scope is front-loaded and there is no filler.

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

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

With no output schema, the description still communicates the return format (sections, one-line summary, link) and the search surface. Combined with a fully documented 3-parameter schema and complete annotations, an agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by enumerating what the 'query' string actually matches against (titles, keywords, section text, explanations, enacted headings), which constrains how an agent should phrase queries. The act and limit params are left entirely to 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 (keyword search) and resource scope: titles, keywords, section text, plain-English explanations, plus BNS/BNSS section headings. It also describes the return shape (closest-matching sections with a one-line summary and a link), so the agent knows exactly what this tool produces versus a section-lookup tool.

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

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

Explicitly says 'Use when the user describes a topic but does not know the Act or section number', which cleanly separates it from the sibling lookup_bare_act_section. It does not name that sibling or state the inverse condition (known section number ⇒ use the other tool), so it stops 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=false, openWorldHint=true and idempotentHint=false, and the description adds real value on top: the external side effect is an email to legal@unifiedchambers.com with a copy to the Senior Partner, declines return a reason, and nothing is sent in the declined path. It does not mention duplicate-submission behaviour or failure modes if the mail transport fails.

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 action and recipient, then the eligibility/decline rules. Dense but every clause carries information (recipients, gating fields, decline semantics); only the parenthetical address list makes it read as slightly heavy.

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 responsibly states what comes back (the acceptance result) and what happens on rejection (reason returned, nothing sent). For a 9-parameter mutation with full schema coverage and an annotation safety profile, this covers what an agent needs; only the shape of the acceptance payload is left unspecified.

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 one of the 9 parameters is already documented, including the claim_inr sentinel value and the forum/matter_type enums. The description only echoes a subset of the fields as the 'engagement range' criteria (organisation, contact, amount, matter type, summary), adding little 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 and resource ('sends a matter enquiry to the firm by email') and even names the recipient mailboxes, so the action is unambiguous. It distinguishes itself behaviorally from the case-management siblings (get_matter_status, list_my_matters) by being the outbound enquiry submission, though it never names brief_new_matter or book_consultation as the neighbouring alternatives.

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 applicability condition ('when the matter is within the firm's engagement range') and two explicit exclusions: below-range matters and advocate empanelment requests are declined. It stops short of pointing the agent to the correct sibling for those excluded cases, so the routing is implied rather than complete.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral detail the annotations lack: sort order ('soonest first'), the restricted scope ('active matters'), and the returned fields (forum, bench, case number, stage).

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 sentence, front-loaded with the action and scope, then the ordering and return fields. Every clause carries information and there is no filler.

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

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

For a single-parameter read tool with no output schema, the description compensates by enumerating the returned fields and the ordering, which is what an agent most needs. Minor gaps remain (e.g., behavior when no hearings fall in range), but nothing essential 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% and the single 'days' parameter is fully documented with range and default. The description only restates the 1–90 bound and default 30, adding no syntax or edge-case meaning 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?

Precise verb+resource ('Lists hearings') with an explicit scope qualifier ('institution's active matters', 'next N days'). It is distinguishable from deadline-oriented siblings like deadline_watch and panel_deadline_tracker by resource, though it never names or contrasts them directly.

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

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

Usage is implied by the scope ('active matters', 'upcoming hearings') but there is no explicit when-to-use or when-not guidance, and no alternative is named for the adjacent deadline/schedule siblings. Adequate but leaves routing to inference.

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