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=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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: it lists exactly what metadata comes back and explicitly notes the precedent text itself is NOT returned here but through the signed-in firm connector, which also signals an authentication/firm-membership requirement.

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, and the field enumeration is informative rather than padding. Slightly dense on the field list, but every listed item (especially the AI-use guidance and licence/review date) tells the agent something about scope that it would otherwise have to guess.

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, and the description effectively substitutes for one by enumerating the returned fields and calling out the one thing it does not return (the full text), plus the connector/auth caveat. For a single-parameter, read-only fetch this is complete enough to call 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?

With one parameter at 100% schema description coverage, the schema already explains that precedent_id comes from search_precedents. The description adds nothing about the id format, prefixes, or error behavior for an unknown id, 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?

States a specific verb and resource ("Returns one published precedent's details") and enumerates the returned contents: summary, when to use it, authorities, AI-use guidance, licence and review date. The singular scope plus the reference to search_precedents (plural search sibling) makes the boundary clear without opening a schema.

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

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

Usage is only implied: an agent infers it should call this after locating an id via search_precedents, which is mentioned only in the parameter description. There is no explicit when-to-use or when-not-to-use statement, and no guidance on what to do if the precedent id is unknown or the precedent is unpublished.

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 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description usefully adds return behavior (open questions, or the required research once complete), but omits whether the record string must be the latest one, how partial answer sets are handled, or any auth/rate constraints. The word 'Adds' is mutation-flavored phrasing against a readOnlyHint=true annotation, though it is consistent with a stateless pass-in/pass-back design, so this is not treated as a 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 sentences, no filler, with the core action front-loaded and the return behavior second. 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 return-value disclosure, covering both terminal states. Parameters and safety are handled by schema and annotations. Minor gap: it does not state what happens on a partial answer submission or whether unanswered questions should be omitted or marked 'unsure.'

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 `record` string's provenance ('the previous workflow tool returned, passed back unchanged') and the `answers` keying/`from` semantics are fully documented in the schema, including per-question descriptions and enums. The description adds no parameter detail, which is acceptable given 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 — adds the user's answers to the work record — and clarifies the object as 'the clarifying questions.' It is distinguishable from siblings like record_research or work_record, though it never names an adjacent tool to draw the boundary explicitly.

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

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

Usage is implied rather than stated: the mention that it 'returns the questions still open' tells an agent this is called iteratively until all questions are answered. There is no explicit when-to-use, when-not-to-use, or named alternative, so an agent must infer the placement in the workflow.

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, non-destructive, and closed-world, so safety is covered. The description adds genuine behavioral context beyond that: the exact return fields (ids, titles, kinds, practice area ids, jurisdictions, review dates) and the limitation that full text is only available 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?

Two sentences, front-loaded with the core action and scope, with the return field list and full-text caveat following logically. The long parenthetical enumerating content types is slightly verbose but does useful work defining coverage.

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 lists the returned fields and notes the full-text limitation, which is the key thing an agent needs to know about result richness. It still omits result-count/pagination behavior tied to the 'limit' parameter, a 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 coverage is 67%, so 'area' and 'query' are already documented in the schema while 'limit' is not. The description references practice area ids and jurisdictions in the return payload, which weakly signals what 'area' filters on, but it adds nothing about the query string or the result limit, so it does not compensate for the coverage gap.

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

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

The description states a specific verb and resource ('searches the published precedent library') and enumerates the searchable fields (title, summary, when to use it) and content types. It clearly reads as the precedent-specific search, distinct from general library lookup, though it never names the sibling search_library or get_precedent to draw the boundary 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 by the phrase 'published precedent library' and the note that full text requires the signed-in firm connector, which hints this tool returns metadata only. However, there is no explicit when-to-use guidance nor any statement about when to prefer get_precedent or search_library over this tool.

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

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

The description says the tool 'opens a work record', which is a state-creating claim, while the annotations declare readOnlyHint=true (no environment modification). The description also does not reconcile this with the idempotentHint=true annotation. Since the description asserts a write-shaped side effect that the annotations deny, this is an annotation 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?

One sentence, front-loaded with the action and the return value, with the parenthetical '(step 1, define the task)' earning its place by fixing the tool's position in the workflow. 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 burden of describing the return, and it does ('the clarifying questions the framework needs answered', minus supplied answers). It omits whether a record identifier is returned for later use by record_answers/work_record, which an agent orchestrating the workflow would want, but the core call path is 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 coverage is 100%, so the baseline is 3, but the description adds genuine semantics: `answers` is not just data, it subtracts from the question set that is returned, implying partial-answer calls are valid. `request` and `agent` are covered by the schema alone.

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

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

States a specific verb and resource ('opens a work record for one legal task') plus the concrete return ('the clarifying questions the framework needs answered'), and anchors it as 'step 1, define the task'. An agent can place it in the workflow relative to siblings like record_answers and work_record without opening any schema.

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

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

The 'step 1, define the task' framing tells the agent when in the framework lifecycle to call this, and 'less any already answered in `answers`' signals the follow-on workflow. It stops short of naming alternatives explicitly (e.g. when to skip straight to record_answers), so it is clear context rather than full when/when-not guidance.

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

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

Annotations 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.