AI Law Framework

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context beyond them: governance is capped by recorded evidence, the manual route is also scored, and the return is a decision with reasons and a preference order.

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 led by the verb, with each clause (three scores, governance cap, manual route, return shape) earning its place. It 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?

Despite no output schema, the description explains the return (decision, reasons, preference order), which is the key gap it needed to fill. With 8 params, nested objects, and 88% schema coverage, the remaining omission is workflow prerequisites, which the sibling set largely implies.

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 88%, so the schema already documents the parameters (record, option_name, adoption/efficiency/governance, conditions, outstanding). The description names the three score axes but adds no syntax, format, or enum semantics beyond what the schema provides, so 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 states a specific verb (Scores) and resource (the AI option) across three named axes, notes its workflow position (step 2), and discloses that it also scores the manual route and returns the decision. It is clear what the tool does, though it never names or contrasts with a sibling tool to disambiguate.

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?

"(step 2)" is a real but thin signal that this runs after a preceding workflow step, and the mention of scoring the manual route implies it belongs in a comparison/decision stage. There is no explicit when-to-use/when-not guidance and no alternatives are named.

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 closedWorld, so safety is covered. The description adds genuinely new behaviour: the response bundles three assessment dimensions plus the court AI rules in one call, and an unrecognised tool is not an error but returns a not_recorded status — a fallback an agent must know about to interpret results correctly.

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 output content is front-loaded in the first sentence and the non-obvious fallback behaviour is placed last where it stands out. 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?

With no output schema, the description carries the burden of indicating what comes back, and it does so only at a high level ("adoption, efficiency and governance" plus rules) without mention of shape or scoring method. It also does not note that jurisdiction will be prompted for if omitted, leaving the schema's 51-value forum enum and jurisdiction handling uncontextualised in prose.

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 explains task, tool, forum and jurisdiction, including the instruction to omit jurisdiction to be asked. The description reinforces the key semantic constraint — exactly one tool on exactly one task — but adds no format guidance for the tool identifier (name versus catalogue profile id) beyond what the schema states.

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 uses a concrete verb ("Returns") and names specific resources: catalogue adoption, efficiency and governance for one tool on one task, plus the matching court AI rules. That is clearly distinct from a plain profile lookup like get_software_profile or a pure rules lookup like find_rules, though it never names those siblings explicitly to sharpen the boundary.

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

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

There is no explicit statement of when to reach for this tool versus get_software_profile (raw profile), find_rules (rules only) or disclosure_duties. Usage is only inferable from the purpose sentence. The one piece of routing information given — that unlisted tools stay not_recorded — is about behaviour, not about when to call 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 the safety profile: read-only, idempotent, non-destructive, and closed-world. The description adds that the duties are 'stored', implying a static retrieval rather than dynamic computation, but says nothing about data freshness, completeness, or behavior when no duties exist.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately states the action, the returned resource, and the scoping inputs.

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 lookup with a rich input schema and annotations, the core purpose is covered. However, there is no output schema and the description does not describe the return value shape, nor does it mention the optional jurisdiction behavior from the schema.

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

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

Schema description coverage is 100% and all three parameters have descriptions and enums. The description adds no parameter meaning beyond what the schema already provides, 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 states a specific verb ('Returns') and resource ('stored disclosure and verification duties') scoped by forum and document type. It is clear what the tool does, but it does not explicitly differentiate itself from nearby lookup tools such as get_jurisdiction_guidance or find_rules.

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 use this tool rather than alternatives, nor any stated prerequisites or exclusions. The usage is only implied by the purpose 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 real value beyond the annotations: it discloses that jurisdiction guidance not tagged to the named forum is split out into a separate `profession_guidance` field and must also be read. That is non-obvious output behavior not present in the schema, and it does not contradict the readOnly/idempotent hints.

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, with the core retrieval behavior front-loaded. The second sentence is slightly tangled ('returned apart, in `profession_guidance`') but still parses cleanly.

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 covers the key result quirk (the separate `profession_guidance` bucket) that an agent would otherwise miss. It does not describe the shape of the matched instruments themselves, but the important completeness gap is addressed.

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 `task`, `forum` and `jurisdiction` including the enum values and the omit-to-be-asked behavior. The description reinforces only the `forum` semantics (out-of-forum guidance routing) and adds nothing about `task` phrasing.

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 stored court/tribunal AI instruments matching a task and forum via a named rule matcher. An agent can tell it retrieves rule instruments, not guidance documents or precedents, though it never names the sibling tools (get_jurisdiction_guidance, search_library) it contrasts with.

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

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

Implies usage through the task+forum framing and the note that forum-less calls prompt the user, but gives no explicit when-to-use/when-not or which sibling to pick instead (e.g., when to use get_jurisdiction_guidance versus this).

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=true, idempotent=true, destructive=false, and openWorld=false, so the safety profile is fully covered without description help. The description adds useful scope context that the payload is a fixed rulebook (steps, pillars, levels, stages, no-exception rules), but says nothing about size, caching, or ordering beyond that.

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 verb and resource first and every enumerated item earning its place. It is one long cumulative list rather than structured clauses, which slightly hurts scanability but wastes no words.

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

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

For a zero-required-param read tool with no output schema, the description adequately covers what content is available. It omits what happens when 'part' is omitted (presumably 'all' but not stated) and gives no guidance on which part to request for which downstream task, which is the main 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 description coverage is 0%, so the description must carry the parameter burden. It does so indirectly by naming each part (five steps, three pillars, decision rule, four levels, seven stages, no-exception rules) in the same order as the enum values, letting an agent map 'part' values to content. It never explicitly cites the 'part' parameter or explains the 'all' default, so it stops short of a 5.

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

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

The description gives a specific verb (Returns) and resource (the AI Law Framework's rules) and enumerates the concrete contents, so an agent knows exactly what domain knowledge it yields. It does not differentiate itself from siblings such as get_jurisdiction_guidance, get_precedent, or get_task_guidance, so a 4 rather than 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 statement of when to call this tool versus the many sibling lookup tools, nor any prerequisite or exclusion. The text is purely a content inventory, leaving the agent to infer that this is the static rulebook behind the other tools.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: an empty gap means no instrument is stored for that forum, and omitting the forum triggers a follow-up prompt for the court. It does not cover permissions or any interactive fallback beyond the forum case.

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 with the return behavior front-loaded and no wasted prose. The phrasing 'Name the forum, or court "no"' is slightly compressed and reads awkwardly, but nothing is 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?

For a 7-parameter read tool with no output schema and high schema coverage, the description covers the core purpose and the two non-obvious edge cases (missing forum, empty gap). It leaves unspecified how audience/document_type shape the returned guidance, but the schema largely carries that.

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 explains task, court, forum, audience, jurisdiction and document_type. The description's parameter remarks (forum naming, court 'no') largely restate what the schema fields already say, so it adds little beyond the baseline.

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

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

States a specific verb and resource: it returns the framework's notes for one jurisdiction plus which stored AI instruments apply to a task in a court or tribunal. That clearly separates it from get_framework and get_task_guidance, though it never names those siblings explicitly.

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

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

It gives conditional input guidance ('Name the forum, or court "no" when no court is involved') and explains when the result is empty, but offers no explicit when-to-use-this vs. get_framework / get_task_guidance / get_precedent routing. 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds one genuinely useful behavioural detail — that court AI rules are conditionally attached when a jurisdiction code is supplied — but says nothing about what happens with an unrecognised area, whether unpublished areas error, or what the prompt payload looks like.

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

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

Two short sentences, zero filler, with the core return value front-loaded and the conditional modifier second. Nothing could be removed without losing 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?

For a simple read-only getter with full annotations and complete enum coverage, the description adequately conveys both what is returned and the one conditional variation. The absence of an output schema is mostly mitigated by naming the two return components (prompt plus attached court AI rules).

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

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

Schema coverage is 50%: jurisdiction carries a rich description, while area has only an enum. Both parameters are enums and largely self-documenting, but the description adds no meaning about how the two interact (e.g. that jurisdiction augments rather than replaces the area prompt), so it does not compensate for the uncovered half.

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 published practice-area prompt for one Australian area'), which is distinguishable from siblings like get_framework, get_precedent and search_library. It does not explicitly contrast itself with the closer-sounding get_jurisdiction_guidance, so it stops short of full sibling differentiation.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named among the many legal-context siblings. The only conditional sentence ('Court AI rules are attached when a jurisdiction code is given') describes output behaviour rather than 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 already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond them: exactly what payload comes back, and the important access constraint that the source text is only reachable through the signed-in firm connector (i.e. this tool returns metadata, not the judgment text).

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 core action, and the enumeration of returned fields is dense rather than padded. The field list is long but each item is informative, and the access caveat is deliberately placed last so it doesn't bury the primary verb.

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 has to describe the return shape, and it does so item by item while also flagging the connector-based limitation. It stops short of stating failure behavior for an unknown or unpublished precedent_id, which is the main remaining gap for a lookup 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?

Single parameter with 100% schema description coverage; the schema already explains that precedent_id comes from search_precedents. The description adds no further format, prefix, or provenance detail, so the baseline of 3 for a schema-documented parameter 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 one published precedent's details") and enumerates the fields returned (summary, authorities, AI-use guidance, licence, currency), which is far more specific than a tautology. It implies but never names the sibling it complements (search_precedents), so an agent relying on description text alone gets no explicit 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?

There is no explicit when-to-use or when-not clause, but the description draws one real boundary: the full precedent text is not here, it lives behind the firm connector. That implicitly tells the agent to use this tool for metadata and route full-text reads elsewhere, which is implied rather than stated 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds genuinely useful behavioral content by disclosing what comes back in the absence of an output schema - facts, governance considerations, and sources with review dates. It does not mention error behavior for unknown product names or how the optional controls filter changes the result set.

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 scope ('one AI product and plan') and the returned payload are front-loaded before the input note. 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?

With no output schema, the description correctly takes on the burden of describing the response shape, which is the most important missing structured information here. It is largely complete for a read-only single-record lookup, with only minor gaps around failure modes for a non-matching product name.

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

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

Schema description coverage is 100%, so both parameters are already documented, which sets the baseline at 3. The description's 'Accepts a profile id or a product name' restates the product parameter's dual-input nature without adding format, resolution-order, or precedence detail 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 ('Returns the framework's research on one AI product and plan') and enumerates the payload: facts, governance considerations, cited sources with review dates. It clearly differs from a search-style sibling, though it never names search_library or another sibling explicitly, so differentiation is inferred rather than stated.

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

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

Usage is only implied: 'one AI product and plan' and 'Accepts a profile id or a product name' suggest a single-record lookup rather than a search. There is no explicit when-to-use, when-not-to-use, or statement of which sibling to prefer for discovery versus detail retrieval.

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 fully covered structurally. The description adds value beyond that by disclosing the shape of the payload (orientation content plus a fictional sample matter), which tells the agent what to expect from the read.

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 that opens with the usage condition and then lists contents. The enumeration is long but every item corresponds to real return content, so nothing reads as filler.

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

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

With no output schema, the description carries the burden of describing the return value, and it does so by itemizing what the agent will receive, including the sample matter. It is complete enough to call correctly for a zero-parameter onboarding tool, though it could note relative size or ordering.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a no-parameter tool applies. The country/state question sequence mentioned in the description is framework content, not input parameters, so no confusion is introduced.

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 uses a clear retrieval verb tied to the framework's onboarding content and enumerates exactly what comes back: what the framework decides, the first questions, the five steps, skills, starting prompts, and a sample matter. It is clear and specific, but it never distinguishes itself from the sibling get_framework, which an agent could easily confuse it with.

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?

"For a new user, or when asked what this is" gives an explicit trigger condition that an agent can act on. There are no exclusions and no named alternatives, so the agent gets clear when-to-use but no routing guidance against get_framework or assess_and_decide.

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. With no output schema, the description usefully carries the return burden by naming the fields returned (AI-use level, lawyer review obligations, checkpoints, restrictions, sources, jurisdiction versions).

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 that states the action first and then enumerates the returned content; there is no filler. The list is dense but every item conveys something about the response.

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, read-only lookup, the definition covers what is fetched, which identifier it needs, and what the response contains. Since no output schema exists, the enumerated return fields are the right thing to include; only an explicit pointer on how it differs from get_jurisdiction_guidance 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 example id format and the optional jurisdiction slug. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema 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?

States a specific verb and resource ("Returns one task from the practice library") and enumerates the payload contents, so the agent knows this is a single-item detail retrieval rather than a list. It doesn't explicitly contrast itself with the similarly-named sibling get_jurisdiction_guidance, so sibling differentiation is only partial.

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 or when-not-to-use statement, but the schema's task_id description ("The task id from search_library") implies the intended workflow: search first, then fetch details by id. 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description usefully discloses the return content (what the lawyer and AI may and may not do at each stage), which matters since there is no output schema; however, the verb 'Sets' reads as state mutation and creates mild tension with readOnlyHint=true. The description does not clarify whether anything is persisted.

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 padding — purpose first, then inputs, then return value. It is dense but every clause carries information; a minor deduction because the clause order (what it sets before what it consumes) is slightly less scannable than it could be.

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

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

For a one-parameter, read-only workflow step with no output schema, the description covers prerequisites, the action, and the shape of the return value. Missing only the explicit step ordering relative to named siblings, which would fully close the loop.

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

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

There is a single parameter with 100% schema description coverage, so the schema already explains that `record` is the string returned by the previous workflow tool and must be passed back unchanged. The description adds only the indirect hint that the record encodes 'the recorded answers, research and decision'. 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 gives a concrete verb and resource — it sets the level of each of the seven stages and returns the permitted/prohibited actions per stage — and locates itself as 'step 3' in the workflow, which helps separate it from siblings like record_answers or assess_and_decide. It falls short of 5 because 'level' and 'seven stages' are undefined domain jargon an agent can't resolve from the text alone.

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

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

Usage is only implied: the phrase 'from the recorded answers, research and decision' signals the prerequisites (record_answers, record_research, assess_and_decide must have run first), but no alternative tool is named and there is no explicit when-not guidance. Adequate but leaves the ordering 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?

The description says the tool 'adds' answers to the work record, i.e. it mutates stored state, while the annotations declare readOnlyHint=true and destructiveHint=false. That is a direct conflict between the stated behavior and the structured safety metadata. The only genuinely additive behavioral detail is the return contract (open questions vs. research), which is undercut by the contradiction.

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 with no filler, and the core action is front-loaded before the return behavior. It could be marginally shorter, but every clause carries information an agent can use.

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

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

Given a 2-parameter but deeply nested schema (16 answer objects) and no output schema, the description does cover the return values and the iterative workflow role, which is the main thing an agent needs. However, for a state-mutating step in a multi-tool workflow it omits sequencing/prerequisites and leaves the readOnly conflict unresolved, so it is only adequately 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 every nested answer object carries its own question text and enum values, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond echoing the notion of a 'work record'; baseline 3 is appropriate when the schema fully documents the inputs.

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

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

States a specific verb and resource: it adds the user's answers to the clarifying questions into the work record, and it also declares what the tool hands back (open questions, then the required research). An agent knows exactly what the tool does, though it never names a sibling (e.g. work_record, record_research) to disambiguate against the similar-sounding tools in this family.

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

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

Usage is only implied: the statement that it returns the questions still open, or the research once all are answered, tells the agent this is called iteratively during the clarifying-questions loop. There is no explicit when-to-use, no precondition (e.g. 'call after get_started returns a record'), and no mention of alternatives such as work_record.

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 real value beyond that by disclosing the two return modes (missing-research list, or the scoring anchors and governance ceiling the evidence sets), which tells the agent what downstream effect the call has. It does not explain the lifecycle of the passed-back `record` token, and the phrase 'Adds ... to the work record' sits in mild tension with readOnlyHint=true, though in a stateless token-passing workflow that is reconcilable.

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 zero filler words. The only weakness is that the second sentence compresses two distinct return modes into a single 'or' clause, which is terse to the point of mild ambiguity about which mode triggers when.

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 the burden of describing returns, and it does give a partial picture (missing research, or scoring anchors plus governance ceiling). It leaves out whether the updated record token is returned for the next workflow step, error behavior, and the 20-finding limit, which are gaps for a tool whose output feeds a scoring workflow.

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

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

Schema description coverage is 50%, at the baseline threshold, and the schema already documents `record` fully. The description does add meaning for the finding payload by naming source, quote and confirmation status, but it is silent on the enum-constrained fields that matter most (item, effect, control, status values, searches) and on the maxItems=20 cap. It compensates only partially for the coverage gap.

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

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

The description gives a concrete verb and resource: it adds research findings, each carrying a source, quote and confirmation status, to the work record. That is far more specific than the title alone and lets an agent distinguish it from assess_and_decide or record_answers. It stops short of explicitly contrasting itself with those siblings, so it lands at a strong 4 rather than 5.

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

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

There is no explicit 'use this when / do not use this when' statement and no sibling is named as an alternative. The clause 'Returns the required research still missing' does imply the tool sits in an iterative gather-until-complete loop, which is usable context, but the agent must infer it. This is implied usage rather than stated 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 readOnly, idempotent, closed-world, non-destructive, so safety needs no restating. The description earns credit by disclosing the return shape (a restatement plus enumerated open questions covering jurisdiction, dates, parties, forum, output, urgency) which matters because there is no output schema.

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

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

A single well-formed sentence with the core behavior front-loaded and the enumerated dimensions carrying real information rather than filler. Could be marginally tighter, 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 two-parameter, non-destructive read tool with rich annotations and no output schema, the description covers what it produces and over what dimensions. It is slightly thin on whether the query is anonymized before use (only in the schema) and on what the agent should do with the open questions next.

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 already documented, including the important PII-stripping requirement on `query` and the enum on `area`. The description adds nothing beyond 'Australian legal question', which is already implied by the title; 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 ('restates') and resource ('one Australian legal question') plus the secondary output (open clarifying questions). It is clearly distinguishable from research-oriented siblings like find_rules or get_precedent, though it never names a boundary against planner tools such as start_task or get_practice_area_prompt.

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

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

Usage is only implied: the description suggests this is a first-pass triage step before research, but gives no explicit trigger, no exclusion, and no named alternative. An agent can infer 'refine before you research' but must guess the handoff point.

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 useful return-shape information ('returns titles, ids and ailawframework.com links') that compensates for the absent output schema, but says nothing about result limits, ordering, or relevance 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 verb and scope, followed by return contents. The long enumeration is necessary for scope but slightly list-heavy; nothing is redundant.

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 search tool with no output schema, stating the returned fields is a real contribution. However, the description omits result-limit behavior (the schema caps limit at 25) and does not clarify ranking or empty-result behavior, leaving gaps an agent may hit in practice.

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 33% and neither the 'limit' cap nor the 'kind' enum is explained in the description. The enumerated entity types do map loosely onto the 'kind' enum values (task, practice-area, jurisdiction, software, obligation), providing partial implicit coverage, but 'limit' is left entirely undocumented.

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

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

The description gives a specific verb ('searches') and enumerates the exact resource types covered (practice areas, tasks, jurisdiction versions, jurisdictions, obligations, software profiles), so the agent knows the scope. It does not, however, distinguish itself from the sibling search_precedents, which is also a search 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The agent must infer from the enumerated entity types that this is the broad discovery tool versus the get_* retrieval siblings, but the description never states that 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 already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them: it enumerates the returned fields and discloses the access limitation that full text is only reachable through the signed-in firm connector.

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, each earning its place: scope and search fields first, return shape second, full-text access caveat last. No repetition of the title and 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 carries the return-shape burden and does so by listing the exact fields (ids, titles, kinds, practice area ids, jurisdictions, law-as-at date). Combined with the full-text access note, an agent has everything needed to call it and interpret results.

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

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

Schema coverage is 67%, with 'query' and 'area' documented in the schema itself (including an example area id). The description reinforces which document fields the query matches and mentions practice area ids among the return values, giving indirect context for 'area', but adds nothing for 'limit' beyond its schema bounds. 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 (Searches) and resource (the published precedent library), enumerates the content types covered, and names the fields searched (title, summary, when to use it). It is clearly distinguishable from fetch-style siblings by being a search over indexes rather than retrieval of a single precedent, though no sibling is named explicitly.

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

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

Usage is implied rather than stated: the agent can infer this is the entry point for finding precedents and that full text requires the signed-in firm connector. There is no explicit when-to-use, when-not-to-use, or 'use get_precedent instead for full text' 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 already declare readOnlyHint/idempotentHint/non-destructive/closed-world, so the safety profile is covered; the description adds genuinely new behavior — the returned question set is filtered by what is already in `answers`, and reads the referenced skill first. Minor tension: "opens a work record" implies state creation, which sits awkwardly with readOnlyHint=true, though it is consistent with returning a question set rather than persisting anything.

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 what the tool does and its return, then the ordering hint, then the prerequisite. Nothing is redundant with the schema or annotations.

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 does explain the core return (clarifying questions, minus those answered). It does not say what else comes back — notably whether a task/work-record handle is returned for later calls to record_answers or work_record — which is the one thing an agent needs to chain 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% and the nested `answers` object documents each question id and the `from`/`quote` semantics, so the schema does the heavy lifting. The description still adds value by explaining that `answers` suppresses already-answered questions and by pinning country and state as the first two to ask.

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?

"Opens a work record for one legal task and returns the clarifying questions" gives a concrete verb, resource and return value, and places it as "step 1, define the task" in the framework flow. It implicitly separates it from record_answers (answers already supplied) but never names a sibling such as get_started, which an agent may confuse with this entry point.

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 a hard prerequisite ("Read the skill ailf://skills/ai-law-framework before the first call") and prescribes ordering for the first two questions. There is clear when-to-use context (start of a task) but no explicit when-not-to-use or named alternative among the 13 siblings.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description does not contradict that ('Returns' matches a read-style operation). It goes beyond the annotations by disclosing the emission format (markdown) and the exact content sections, plus that checks/approval/release are deliberately left to the lawyer rather than resolved by the tool — useful context the annotations cannot carry.

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 verb first and the section list used purposefully rather than as filler. The trailing list item ('the checks, approval and release left for the lawyer') is slightly compressed but still readable.

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

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

With no output schema the description does carry the return-value burden and does so at a summary level, but for a tool with six parameters including nested objects it leaves gaps: the opaque reference to 'steps 4 and 5', no indication of where the markdown goes or how large records are handled, and no coverage of several parameters.

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

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

Schema coverage is 67%, so a mid-tier baseline applies. The description maps some content to parameters ('what the AI did' matches agent_did, 'the checks' matches check_points/lawyer_checkpoints) and implies record carries task/evidence/decision/plan, but it says nothing about notes, output.title, or output.version, so it only partially compensates.

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 work record as markdown') and enumerates the exact sections it emits (task, evidence, decision, plan, agent actions, remaining checks/approval/release). That is far more concrete than siblings like record_answers or record_research, though it never explicitly names a sibling or contrasts its role with them.

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

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

The only positional cue is the parenthetical '(steps 4 and 5)', which hints at a workflow sequence but is meaningless without the surrounding pipeline. There is no statement of when to call this versus record_answers/record_research/plan_human_work, no prerequisites, and no exclusions.

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